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?.
Recent comments
Thank you! Your quick reply was very, very much appreciated.
I have killed my site, changing the 'Public File System Path' How to fix
If you have FTP access edit the file... system.core.json Which is in... /files/config_[lots of random numbers]/active Line 35 (on mine) is "file_public_path...
I have killed my site, changing the 'Public File System Path' How to fix
It was the image. I deleted it and the problem went away. Whew.
CKEditor 5 Not Saving Changes, Can't Access Source