Improve handling of regional locales

[etpinard]

Follow-up on #2683

From @alexcjohnson 's

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?

which I replied:

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.

where we then settled on:

---

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.

---

with one caveat:

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.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson