[UX] Improve current Language System

This is some kind of feature request to improve the language system in Backdrop (maybe for 2.x?), also related to issues #827, #860 & #886.

It could be a good opportunity to simplify the whole thing by moving interface texts from DB into flat config files. Some examples of other language systems out there: - Modern framework-based CMSs (Bolt, October, etc.) use .yml files. - ProcessWire uses .json files. - WordPress uses .po / .mo native Gettext files. - Most other CMSs use native PHP files (constant definitions).

A remake example

Since interface texts are quite static and CMI is already using json, why not use something similar for interface languages? A possible folder structure for French: - core - languages - Core - Modules - node.fr.json - Themes - bartik.fr.json - Modules - insert.fr.json - Themes - radix.fr.json - layouts - modules - profiles - sites - themes

insert.fr.json file example:

{
"_module_name": "insert",
"_language_code": "fr"
"Insert": "Insérer",
"Upload": "Télécharger"
}

Then, t() & st() could be replaced with something like locale_set(), locale_get() & locale_del().

I would also merge Language and Locale modules into one single module to avoid confussion: Locale needs Language, and Language with Locale disabled is quite useless. It would be easier to have one module for a "non-English site" scenario, and an additional module for a "multilingual site" scenario.

Possible pros

• UX: easy edition & maintenance. No need for external tools. No more complex DB optimizations needed (obsolete versions, contexts, strings saved as BLOB, etc.).
• Easy to override and set default preferences (e.g. look for custom translations in files/languages first, and fall back to /languages or modules/MY_MODULE/languages).
• Performance and database size. No more "execution timeout" errors when importing translations or installing in other languages.
• No localization server needed at backdropcms.org. Translations can be easily maintained e.g. here on GitHub, and fetched from backdropcms.org like any other project.
• Implementation and consistency; for module/theme developers it's similar to current "config" or "states".

Possible cons

• Massive changes: worse long-term Drupal compatibility.
• No backwards compatibility for current (1.x) core, modules or themes.
• Worse multilingual (Content Translation module) integration?.