This is a simple patch for bootstrap.inc, which adds a function call for all the variable functions (variable_get, variable_set, variable_del).

This adds support for language-dependent variables, and does nothing when i18n.module is disabled.

The idea is to add a language prefix to the variable name, depending on current language, thus allowing to easily translate some variables to different languages.

CommentFileSizeAuthor
#10 i18n_lang_vars.patch883 byteschx
#8 i18n_language_variables_1.patch861 bytesAnonymous (not verified)
#3 i18n_language_variables_0.patch1.07 KBchx
#2 i18n_language_variables.patch975 byteschx
i18n_language_variables_01.patch1.16 KBjose reyero

Comments

chx’s picture

chx commented

So simple, so useful. For example theme settings can be an i18n variable, thus your name, mission etc can be international without any more code.

chx’s picture

chx commented
StatusFileSize
new i18n_language_variables.patch975 bytes

Following moshe's advice from http://drupal.org/node/16069 here is another, more readable version.

chx’s picture

chx commented
StatusFileSize
new i18n_language_variables_0.patch1.07 KB

:( Wrong file.

chx’s picture

chx commented

Forget these and stick to jose's patches. module_invoke is not available at this point...

Steven’s picture

Steven commented

Not all variables contain text and not all of them should be possible to change randomly. This whole approach to internationalisation seems a bit backwards to me: there will always be tables with text that you haven't translated. Shouldn't we be doing this at the string level? That's the only thing that should be changed, no?

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Steven, doing it on the string level is not possible without heavy Drupal patching. Doing it on the variable level would open up some doors at least. It would not enable menu translation for example, but it would enable a lot of stuff to be translated. With a horrible UI by the way, where you would need to swicth the complete UI language to translate the user registration mail or the story submission guidelines to another language... It might not be the best way to go, but it is the only way to advance right now, or the i18n effort will get stuck until 4.7 comes around.

jose reyero’s picture

jose reyero commented

The variables to be translated are to be defined in the config file, but a list of variables 'worth being translated' will be included in i18n documentation. Though maybe this is not an optimal approach from the db point of view -language is stored in the variable name itself-, I think it is the better one when you balance functionality/flexibility/patching required.

About the interface, I agree with Goba. But this patch is only about core support, a specific interface may be added later as a part of i18n module.

Anonymous’s picture

(not verified) commented
StatusFileSize
new i18n_language_variables_1.patch861 bytes

Update to HEAD

chx’s picture

chx commented

former post is mine (chx)

chx’s picture

chx commented
StatusFileSize
new i18n_lang_vars.patch883 bytes

Well, the patches have not made it for 4.6, let's see what we can do for 4.7. To begin with, I reroll the patches.

chx’s picture

chx commented
Status: Needs review » Closed (won't fix)

No longer needed.