Open pablo-romero opened 9 years ago
Thanks for opening this issue @pablo-romero. I'd like to investigate the option of using .po
files directly. I think it's absurd that Drupal uses the database for string translation, but I'm sure there's some historical reason for it. WordPress's approach actually isn't even custom, .po
file support is built into PHP itself. Their main translation function is the double-underscore function __()
, which eventually leverages PHP's gettext()
function.
I also like WordPress's implementation that it supports contextual translation (I don't think Drupal supports this), e.g. from http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/
$string = _x( 'Buffalo', 'an animal', 'plugin-domain' );
$string = _x( 'Buffalo', 'a city in New York', 'plugin-domain' );
$string = _x( 'Buffalo', 'a verb meaning to confuse somebody', 'plugin-domain' );
And I also like .po files because they work with existing paradiagms. Drupal already uses .po files, but it only leverages them for the purpose of importing them into the database. If were were able to start leveraging them directly, we could skip the import step. Most translation services also support the .po format; using an existing standard helps us with compatibility outside our own software.
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.
I think we'd still need a localization server, as the value of the localization server is empowering anyone to contribute translations without needing to understand GitHub or whatever format we decide upon. It also makes tracking removed/added strings a lot easier if that's done automatically instead of manually running a potx string extractor on our modules.
Thanks for the answer @quicksketch.
That contextual translation example is exactly what I think BD needs. It would probably fix all current issues.
I'd like to investigate the option of using .po files directly.
Then, WP is the best example. There's also an old patch for D7 in this article, not sure how much it could help.
I think we'd still need a localization server, as the value of the localization server is empowering anyone to contribute translations without needing to understand GitHub or whatever format we decide upon.
You're right, I just wasn't sure if you'd want to implement and maintain it.
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:
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:
insert.fr.json file example:
Then,
t()
&st()
could be replaced with something likelocale_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
Possible cons