improve docs on loading and applying locales

[cpsievert]

No description provided.

[etpinard]

Perhaps even better, we could ask translation authors to add an entry in a table of "fully" supported localizaion instead of linking to a list of PRs/

[etpinard]

I think this section is misleading. A priori de-CH doesn't depend on de. At the moment, de-CH fallbacks to de just because de-CH isn't "fully" supported.

[etpinard]

So, I propose we use a "fully" supported language for this example and invite folks we want to use a non-fully supported localization (e.g. de-CH) to contribute by making a PR.

[alexcjohnson]

I notice that de-ch probably doesn't work the way we'd want it to. As far as I can see it's identical to de in the fields that exist, but de has added the dictionary and decimal separators. The way our localization framework is set up, that means de-ch on top of de will behave identically to just de because the fields not contained in de-ch will just be taken from de. AFAICT the only difference there should be between the two is perhaps with decimal separators (which are not part of the world-calendars/kbwood/calendars framework these originally came from, because that only deals with date & time) - so ideally we'd collapse de-ch to just:

module.exports = {
    moduleType: 'locale',
    name: 'de-CH',
    dictionary: {},
    format: {
        decimal: '.',
        thousands: ','
    }
};

Something similar can probably be said for all the regional locales currently in the repo... so before we invest more energy in spelling out how to use regional locales we should probably discuss and agree on how we really intend these to be used: do we want the regional locales to always be layered on the base language locale, or should they be independent?

We have at least one case right now where you can't layer: we have a contributed Brazilian Portuguese (pt-br) but no pt - so anyone currently using pt-br would see stripping that one down to just its differences with pt (once we have a pt) as a breaking change... on the other hand it's really nice if new translations get added to the base and they are automatically inherited by the regional locale. I'm not sure the right way to go about this. Thoughts?

[etpinard]

I'd vote for making all locale dist files (base and regional) standalone, that way users only have to import one file to localize their app.

The only drawback I can think is for app that want to display multiple locales. In this case, importing a base locale along with its regional variants will lead to a few duplicated kBs.

[alexcjohnson]

I'd vote for making all locale dist files (base and regional) standalone, that way users only have to import one file to localize their app.

The only drawback I can think is for app that want to display multiple locales. In this case, importing a base locale along with its regional variants will lead to a few duplicated kBs.

What if we do this in code? ie have lib/locales/de-ch.js be:

module.exports = Lib.extendDeep({}, require('de'), {
    name: 'de-CH',
    format: {
        decimal: '.',
        thousands: ','
    }
});

Then dist/plotly-locale-de-ch.js could contain the output of that code, so it would automatically get updates from de. Users providing both as script tags would still have to carry the extra bytes, but the most byte-conscious users make custom bundles, and a bundle containing both would not have any extra bytes.

[etpinard]

What if we do this in code? ie have lib/locales/de-ch.js be:
so it would automatically get updates from de. Users providing both as script tags would still have to carry the extra bytes, but the most byte-conscious users make custom bundles, and a bundle containing both would not have any extra bytes

Amazing. 🥇

This doesn't solve the pr-br vs pt case though. We should try to find a pt speaker.

[alexcjohnson]

This doesn't solve the pr-br vs pt case though. We should try to find a pt speaker.

That's a (hopefully) uncommon case, where 3/4 of the language's speakers are in a single non-base region (and 20x the number in the base region) - I have no idea how different the two are, but I think it's OK to leave as is for now - hopefully a user from Portugal will come along and make us a pt and then we can collapse the two if they do have enough overlap that it's justified.

[etpinard]

Moved to #2991