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
Looks like this one, and I spotted an error with the hook_config_info() implementation, now fixed: https://github.com/backdrop-contrib/uc_csv
Backup & Migrate Import errors
Hi onyx. Rules are extensible through hooks. Take a look at the file rules.api.php, inside the rules module folder. That has quite a bit of example code. You can create new actions, new...
Rules for Developers
Well, removing those files did it, thank you for your help. But I have no idea what module uc_csv is?
Backup & Migrate Import errors