Refactor i18n system to support plugins, and be more standard

[BeksOmega]

Is your feature request related to a problem? Please describe.

Blockly's i18n systtem doesn't easily support translating developers' custom blocks, or plugins. It relies on reassigning properties on the message object, which isn't very safe, testable, etc.

Describe the solution you'd like

Have a more standard i18n solution, that supports outside devs (eg people making blocks or plugins) easily i18ning their creations.

I'm not sure what a "standard i18n solution" but jQuery.i18n might be a good place to start. Someone could also talk to Oppia, and see how they handle things.

Or maybe we stick with the same translateWiki JSON format, and just take that in instead of relying on Blockly.Msg.

[mark-friedman]

Thanks, @BeksOmega!

[alschmiedt]

Related to RaspberryPiFoundation/blockly-samples#807.

[cpcallen]

I'm not too familiar with existing solutions here, but one possible route would be an API that consists of one or both of:

• A function like Blockly.loadTranslation({locale: 'en', ADD_COMMENT: 'Add Comment', ...}) that loads the supplied translation and (perhaps) selects it for use. (This is a bit like what the existing Blockly.setLocale function does—but note that here the translation is tagged with a locale, the implementation is assumed not to be mutating exported properties, and adding a translation needn't necessarily cause it to be immediately used.)

• A function like Blockly.setLocale('en'), which either selects from amongst pre-loaded translations, or (better) auto-loads the requested translation on demand. (Such auto-loading can be done using require() in node.js and using import() ES2020, which apparently WebPack can support in older browsers.)

Not too sure about how to handle plugins, though, beyond providing a Blockly.getLocale() method to query the current locale.