Initializing without a country code should find l10ns with a country code

[papeh]

• Install Palaso with palaso.zh-CN.xlf
• var palasoLocMan = LocalizationManager.Create("zh", "Palaso", "Palaso", version, installedL10nBaseDir, userL10nBaseDir, CommonResources.chorus, FlexLocalizationEmailAddress, "SIL");
  Expected: a zh-CN LocalizationManager is initialized w/o user input
  Actual: a dialog says Chinese is unavailable and prompts the user to choose a different language from { English, Chinese (China) }

This would resolve https://jira.sil.org/browse/LT-21232, but that was also resolved client-side.

[papeh]

Do we care what happens if both zh-CN and zh-Hans (or -HK, -TW, or -AU) are available?
If a client requests zh-HK but only zh-CN is available, should we pick that? (presently, the answer is yes in another area of L10nSharp)
Barring any strong opinions, I plan to leave the above behaviour undefined.

[tombogle]

I'm not an expert on Chinese, but these can be tricky questions. For some languages, including Chinese, there is more than one script, and while the spoken language might me more or less the same, there is no guarantee that a person who reads one script will have any ability to read another. Where there is a single predominant script, an generic language tag should probably select that script without asking. Where there are multiple scripts or country-specific variants with no clear default, it's presumably better to ask than to blindy select one. But if the differences between the two are relatively minor (e.g., en-US vs. en-GB), there might be times when it is better to select one and leave it to the user to select the preferred one later if they need to.

[tombogle]

See https://www.w3.org/International/articles/bcp47/#macro

[papeh]

Right, this is tricky. Unfortunately, L10nSharp doesn't work with language tags apart from extracting the bare language code to find matches. Without shipping langtags.json, it would be impossible to know whether we're looking at en-US vs. en-GB or zh-Hans vs. zh-Hant (simplified or traditional script). Do you think the existing code should be changed to require an exact or more generic match?

I agree that it may be better to allow the user to choose if there are multiple matches.

[tombogle]

My two cents:
If the caller requests a more specific tag, I think it probably makes sense (and is at least unambiguous) to return the most specific more generic match. It's extraordinarily unlikely that we would ever have an es and an es-ES, but if we did and the caller requested es-ES-blah, then they should get es-ES rather than es. (This might be so unlikely that it doesn't even warrant an implementation...)
If they request a generic tag, and there is exactly one more specific match, it's probably reasonable to return that one.
If they request a generic tag, and there is more than one more specific match, we should ask.
If they request a generic tag, and there is an exact (generic) match, we should return that exact match even if there are other more specific matches.

[papeh]

Present behaviour (v6.1.0-beta008):
If we (or a client) attempt to load zh first when it does not exist, zh will always map to zh.
If we (or a client) attempt to load zh-CN first when zh does not exist, zh will map to zh-CN. #110 will not change this.