[localize] Make all components forward compatible with dialects

[bashmish]

I want all components to work with all locales for languages we have in ./translations/, while at the same time support polymer-cli for the ones we manually define in static get localizeNamespaces().

It is easier to illustrate my idea with the code.

Imagine we have ./translations/en.js and such code:

static get localizeNamespaces() {
  return [
    {
      'lion-component': locale => {
        switch (locale) {
          case 'en-GB':
          case 'en':
            return import('../translations/en.js');
          default:
            throw new Error(`Unknown locale: ${locale}`);
        }
      },
    },
    ...super.localizeNamespaces,
  ];
}

Then this code will work for en-AU and en-US thanks to just one change and this feature of localize:

static get localizeNamespaces() {
  return [
    {
      'lion-component': locale => {
        switch (locale) {
          case 'en-GB':
          case 'en':
            return import('../translations/en.js');
          default:
            return import('../translations/${locale}.js'); // changed
        }
      },
    },
    ...super.localizeNamespaces,
  ];
}

This implies that fact that 2 requests will be needed for locales which don't have a file in ./translations/, because this is how this feature works. But we knew that when we designed it and that was a trade-off, it is just weird we are not using it since then ourselves.

This forward compatibility is useful for people using native dynamic imports or/and webpack for bundling, because they can then use existing languages that we already support, e.g. English, for other countries. For example, most of changes like this for "en-PH" will not be needed for them, unless they also need to support polymer-cli.

I would say the fact we are not forward compatible with modern standards is a bug.

[daKmoR]

for my understanding, you want to do this replacement everywhere?

-          default:
-            throw new Error(`Unknown locale: ${locale}`);
// -----------------------
+          default:
+            return import('../translations/${locale}.js');

[LarsDenBakker]

This should work, I think polymer-cli just leaves dynamic imports with expressions untouched.

Also what's important here I think is that the dynamic imports and the translation files are statically analyzable. That way we can create build-time optimizations per application to smooth out performance penalties.

For example I've been experimenting with a webpack plugin which throws away language files for locales we don't use, and creates entrypoints with inlined translations for each locale for performance. We could make it so that it checks during the build whether there is a locale file available, and otherwise imports the language file. That way it will do 2 imports during development, but 1 import after building for production.

[tlouisse]

Good idea.

Questions:

• Do we also need a fallback for languages not found?
• Will we ever be able to resolve the FIXMEs? Would it maybe be an idea to autogenerate this switch statement as a prepublish script, so we keep the source code succinct and maintainable?

[bashmish]

Fixed in #102

[bashmish]

@tlouisse good questions

Do we also need a fallback for languages not found?

Like English for whatever was not found?

Will we ever be able to resolve the FIXMEs? Would it maybe be an idea to autogenerate this switch statement as a prepublish script, so we keep the source code succinct and maintainable?

Yes, we discussed this already a while ago when we were still on bower. Yeah, looks like a great idea to me to just use NPM prepublish for that, should be doable and simpler than solutions discussed previously. I will create an issue for that!