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
Hi I added the 2 additional settings in settings.php, did a restart - and the error disappeared! Thanks for the support! (but the issues with the conversion still remain .....
Problem with utf8mb4 Format when importing database
With JQuery, simple and fast. Or put all possible links in one menu, and hide unnecessary with CSS mediaquery.
Different primary menus depending on the viewport size?
I wonder if what is happening here is the default database settings are for utf8mb4 if the database server supports it. In settings.php or settings.local.php if that's where you put your...
Problem with utf8mb4 Format when importing database