Problems with language codes longer than 2 chars

[bennypowers]

Description

I'm defining element language by checking document.documentElement.lang.

ready: function () {
  lang = document.documentElement.lang;
  if (lang == '') {
    lang = 'en';
    document.documentElement.lang = lang;
  }
  this.language = lang;
  this.toggleRtl(lang);
},

resources has strings arranged according to these 2-letter codes.

{
  "en": {"colors": "Colors"},
  "fr": {"colors": "Couleurs"},
  "ru": {"colors": "Цвета"},
  "ar": {"colors": "الألوان"},
  "he": {"colors": "צבעים"}
}

Works great until I load my element on a page that has a longer language definition for example lang="en-US", lang="fr-LU", or lang="zh-Hans".

I've worked around this by slicing out everything after the 2nd character, but there are cases where this would break translation (China, I'm looking at you)

lang = document.documentElement.lang.slice(0,2) ;

Expected outcome

app-localize-behavior should flexibly adapt to a variety of language code formats, falling back to acceptable alternatives in resources, should they exist.

Actual outcome

app-localize-behavior fails on language codes which don't exactly match those listed in resources, should they exist.

[bennypowers]

Just a little added info, it was mentioned that app localize behaviour is meant to exactly map to the language code in use, and is not necessarily meant to match the document language. However, for an element which is meant to be used on arbitrary documents, I will have to deal with this issue either by truncating the document language code to 2 chars or by duplicating my strings in locales.json for each regional variant.

[notwaldorf]

I don't think app-localize cares at all what you name your language. You can have something like:

{
  "en": {"colors": "Colors"},
  "batman": {"colors": "nanananana"},
}

And it will use batman accordingly. If your app wants to use the document language code, then yes, I recommend truncating that to the languages that you have defined in the json file.

(alternatively, you can have custom logic in your app that tries to use en-US, and if that doesn't work, falls back to en)