Freeform text should be per-locale

[stuartpb]

Fields of open-ended text like notes and redflags should be changed to use objects with the language code for the language the notes are written in (to permit them to be localized in applications that present notes to the user).

[stuartpb]

Other freeform fields like "must" and "mustnot" should be localizable as well. (Each array item would be an object of locales.)

Should "name" be localized? I feel like that's a job for an alternate field, since names are usually universal.

(Maybe a "markets" array that lets you specify alternative formulations for certain fields, where markets use different locales? Hm- I think that's overkill since it would lead to stuff like every URL being specified for every possible country code for Google or something which doesn't really add stuff? IDK, this is probably worth another issue)

[stuartpb]

Also, while we're doing this, we should also allow "url" as a value, when the effective value is best explained on a (potentially localized) page. (We don't bother with trying to localize URLs, so I think this is best - if it's a localizable URL, it probably deserves to be a link within per-locale text.)

The specific use case I'm thinking here is for Mozilla's Persona, but I think it could also do well for linking to the Wiki or Issues on GitHub for this repo.

[stuartpb]

Should "notes" be changed to an array, then? I think... yes. That way, each "note" can be localized individually. (Indeed, most freeform fields should be arrays of localized objects like this.)

[stuartpb]

Also, while we're documenting freeform text structure, let's also say it should be parsed as Markdown with URLs auto-recognized. That codifies backticks and asterisk-emphasis. (And, of course, you don't have to parse Markdown.)

[stuartpb]

This should be codified in a separate document describing the patterns of fixed complex value structures (stuff like "freeform note lists").

Or, actually... we can just do one header with all the things that use freeform this stuff, so:

• password.rules.must
• password.rules.mustnot
• notes
• *.notes
• redflags

[stuartpb]

This is the fallback logic a consumer should look for values in where, as a soft policy, there will always be a string at one of these fixed values:

• url
• any locales for the user (so pt_BR then pt for a Brazilian Portuguese user)
• en
• en_US (when there's no base English version but there's en_US and en_GB)

[stuartpb]

Locales of text are labeled with BCP47-style keys (where locales may be distinguished beyond the lower-case language code with a capitalized country code), with underscores in place of hyphens. The simplest tag is picked for each localization: more complex tags may be used when writing alternative formulations that are more dialect-specific. (For instance, if the initial Portuguese localization of a freeform field were written with Brazilian Portuguese isms, it would be under "pt": a pull request to introduce a European Portuguese version would change it so there are "pt_BR" and "pt_PT" fields.)

---

Fun fact: until now, I never realized this convention is a combination of ISO standards that is not, itself, an ISO standard - http://en.wikipedia.org/wiki/Language_localisation (which I only found by Googling "en-us pt-br") revealed that the most standard document for this is maintained by the IETF.

[stuartpb]

This should maybe be followed up with / condensed into a "Locale Policy" similar to the "URL Policy" of #27 saying that an English (or en_US) version of any note should be included along with the target language, as a guaranteed last-chance fallback.

Such a locale policy might do well to be coupled with a content-diversity statement (or at least a tie-in to it) like #9.

[stuartpb]

To be honest, I think this might be worth jumping the queue on #42, just to come up with a special case for ensuring this structure is strictly adhered to, since it's a crucial structure, and one it's easy to accidentally not follow.

[stuartpb]

Actually, I think I found somewhere in making the Dictionary of Reserved Words that this locale format is some kind of standard beyond the IETF.

Anyway, also noting that eBay's profile uses a url localization entry.

[stuartpb]

I'm thinking localizations or whatever ("markets" is just, ew) can be an object with the same kind of key format as the other localization objects, but it contains objects instead of strings, with values like:

• some kind of object / array of objects describing that a given pattern should be replaced with some other value in URLs to move them to that localization
• a shim object that's a full overlay to merge-patch over with (overwriting any non-object value), because it's always possible that something's up with a template so that one region doesn't get asked for the password twice or something.

Also, maybe there should be a field for profiles of domains that are profiled but in a specific localization should use, like google.co.uk would have locale: en_GB alongside use: google.com.

[stuartpb]

Eh, the diversification of localization can be pursued and discussed in #17 or whatever the cross-repo successor to that issue is going to be, for v0.2.0 or later; this issue's point is, with some caveats (for example, name is a single-string value for legal documents per #252), settled. I'm only keeping this issue around until all profiles can be validated against the "serious schema" (#146), at which point this will be closed.

[stuartpb]

Okay, so, all profiles do validate against the schema now, but the validator still doesn't process notes, which is kind of the most common kind of description list in the entire schema (so to speak, as notes are only quasi-schema right now, as just described in opws/opws-validate#2).

I'll close this, as the concept it originally introduced has definitely landed, but with the open lament that it feels kind of empty, as this structure isn't being enforced against the one kind of property it was originally written for.

[stuartpb]

Resolving that lament is being tackled with opws/opws-schemata#1

[stuartpb]

Per #308, further discussion of the subjects in this issue should be conducted on the opws-schemata issue tracker (such as in opws/opws-schemata#12, which rethinks the structure introduced by this issue).