Localization as overlays/patches/shims

[stuartpb]

I've been thinking about this a bit after writing #11: it really would make more sense to have localization that could apply to any aspect of profiles rather than just the prose sections.

I didn't like the idea of having localization live as patches within the document they patch (the recursion just gives me a bad feeling), but I wouldn't mind the idea of having them live next to the structure.

Another reason I initially structured the layout the way I did is that I didn't like the approach taken by justdelete.me where English is considered the intrinsic "default" for the data: while there's still a guideline like that in OPWS, it's not codified, and the places where English is used (prose descriptions), it's separate.

However, it could be arranged so that anything as heavily-English as prose descriptions now would live somewhere like l10n.en (or l10n.en_US), alongside the purely-structural stuff.

A thought is that, if we go this route, it should provide separate facilities for internationalization (as described in opws/opws-dataset#17) and localization: you can have someone living in Brazil that speaks Japanese, and that person would want the Japanese translation of the information of the Brazilian regional variant. (For this reason, I think any schema to introduce internationalization, in terms of non-prose differences, would probably come after the one that introduces localization in terms of sheer language translation, and it would probably work as a whole new structural layer, like legacies/.)

This issue builds off of discussion from opws/opws-dataset#12, though it's not strictly the same conversation.

[stuartpb]

This would also make it less awkward when a site's name is generally globally the same, except in certain languages: the main name would be listed as name, which would be overridden by the few differing localizations.

[stuartpb]

The main straight advantage this has over the current design is that it lets URLs be rewritten to have language signifiers.

[stuartpb]

I think any schema to introduce internationalization, in terms of non-prose differences [...] would probably work as a whole new structural layer, like legacies/.

This is a bad idea, for all the same reasons as why l10n should live in the same file as the profile itself: it's data you don't want to make easy to inadvertently fail to keep in sync.

[stuartpb]

For a moment, I was thinking about making it so fields allowing freeform text could only appear in localization shims, then I realized why that's not necessary: sometimes the freeform text can be non-localized, in that it can consist solely of a URL (this is the case for Tarsnap, for instance).

Also, I'm thinking localizations probably will live as text-replacements, with the caveat that not all profiles will be guaranteed to be primarily in English, and may instead choose to use the most likely lingua franca for consumers of the site (meaning profiles will need to have a "language" that refers to the profile's language, and probably the site's default language, and localizations will live as a list of merge-patches with different language properties, each of which should be the first property heading the patch).

And, of course, it'll still be possible to have a profile without a language option - it'll just have to contain no prose of any kind (other than the name, which'd be assumed to be universal).

[stuartpb]

As for what I was saying about internationalization separate from localization... eh, I think I'll just go with the stance that any site that has different regional operation on the same domain and isn't just conflating it with language isn't worth documenting.

That said, there will probably be a decoration for use to denote alternate regional entry points for a site with a shared backend (eg. google.co.uk), and potentially something similar if I ever come across a site with an identical codebase but non-shared backend for different regions - which'd probably get documented as a stack (#3).