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 - - Themes - - Modules - - Themes - - layouts - modules - profiles - sites - themes 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 Translations can be easily maintained e.g. here on GitHub, and fetched from 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?.
GitHub Issue #: