Site settings translation with textgroups

Here is a greatly revised patch:

- the locale translation editing form is "powered up" with some identifiers for easy form altering
- modules defining text groups can go in and provide their custom UI for string translation based on the text group and location
- system module defines the 'site settings' text group and provides custom form fields for editing the site settings via form_alter

Some notes:

- If you did not save a settings screen before, or if you 'reset to defaults', you don't get those particular variables for localization. Reorganized variable default values could help here, but regardless of my call to arms on the dev list, and this nice issue: http://drupal.org/node/145164, noone took the helm yet unfortunately.
- Settings page developers should be careful to variable_get() their settings with the default value (pass NULL as language), so the admin pages always show and edit the default values, and translations are on the translations page.
- This implementation only works with form elements which are easy to pull out from their functions. More complex form elements might need some refactoring. Let's collect a list of settings to offer for translation in Drupal 6!
- This implementation works with string or numeric values, which can be saved as strings. Arrays and objects cannot be saved as strings in the locales tables, but as discussed with Dries, it is unlikely that you would like to offer such values for localization (but see below!).

Extensibility:

- $conf[$langcode] is also used to collect settings translations from out of the locale system, so it is possible to localize any settings, whether they are strings, numbers, arrays or objects.

Patch against Drupal 6.x-dev attached. To understand what happens, I have uploaded a short video to demonstrate the functionality. Although I did not underline the custom form editing widgets in the video, you will be able to notice them on the interface. VIDEO HERE: http://hojtsy.hu/drop/DrupalSettings.mpeg

Here is a greatly revised patch:

- the locale translation editing form is "powered up" with some identifiers for easy form altering
- modules defining text groups can go in and provide their custom UI for string translation based on the text group and location
- system module defines the 'site settings' text group and provides custom form fields for editing the site settings via form_alter

Some notes:

- If you did not save a settings screen before, or if you 'reset to defaults', you don't get those particular variables for localization. Reorganized variable default values could help here, but regardless of my call to arms on the dev list, and this nice issue: http://drupal.org/node/145164, noone took the helm yet unfortunately.
- Settings page developers should be careful to variable_get() their settings with the default value (pass NULL as language), so the admin pages always show and edit the default values, and translations are on the translations page.
- This implementation only works with form elements which are easy to pull out from their functions. More complex form elements might need some refactoring. Let's collect a list of settings to offer for translation in Drupal 6!
- This implementation works with string or numeric values, which can be saved as strings. Arrays and objects cannot be saved as strings in the locales tables, but as discussed with Dries, it is unlikely that you would like to offer such values for localization (but see below!).

Extensibility:

- $conf[$langcode] is also used to collect settings translations from out of the locale system, so it is possible to localize any settings, whether they are strings, numbers, arrays or objects.

Patch against Drupal 6.x-dev attached. To understand what happens, I have uploaded a short video to demonstrate the functionality. Although I did not underline the custom form editing widgets in the video, you will be able to notice them on the interface. VIDEO HERE: http://hojtsy.hu/drop/DrupalSettings.mpeg

1. Yes, the -1 and NULL are different because -1 means: use the page language, NULL means: use the default language. The default is -1 to use the page language, so variable_get() will return strings in the page language if not told otherwise. Of course we can introduce new constants there. Have good ideas? LANGUAGE_USE_DEFAULT and LANGUAGE_USE_PAGE are quite ambiquos, LANGUAGE_DEFAULT and LANGUAGE_PAGE is misleading because the constant values are just instructing the function to do something, not represent the language code themselfs.

2. Good idea!

3. Update now means that we update the source string in the locales table to let it be in sync with the variables table. It does not invalidate the translation, as we don't have tools for this ready.

4. Performance. Well, do get a list of variables for localization in locale_variable_update and iterate through them to find whether the currently variable is for localization. If it is not, we don't do anything. I don't think we can do less in variable_set(). I thought about adding the variable update call to system module's default settings submit handler, but that would only work for settings form, not when a variable is modified programatically, so the locale tables can easily get outdated.

New patch attached to fix $variable_language to $langcode and more documentation on what locale_variable_update() updates. Awaiting a good idea for the constants on variable_get() language codes.

Updated patch to post-schema API code to avoid offsets when applying :) Otherwise the very same code.

I think using textgroups for variables is a good idea but *only for translatable texts*, not for any other kind of setting.

Yes, as you have seen the discussion, a realistic target for Drupal 6 seems to be translatable texts. As I have noted this patch includes a $conf array extension, which allows anyone to add any kind of translated variables, not just text.

We really don't need specific interface for translators if we use this only for text variables.

What specific interface? You mean help text for user email tokens? I think those are important to have for a translator, so he knows what tokens she can use.

There's some other locale query with an inner join, that causes an error when editing these texts.

Maybe you can point that out?

That -1 parameters to get variable defaults is not very clear. I have a 'variable_get_default' proposal in the other patch

Good idea!

The variable initialization for language shouldn't be in locale module, but in language.inc, It is done before module loading.

Well, in this patch, translated variables are collected when the first request comes in for a variable in a language. Not necessarily in bootstrap time. It works for me this way, and it is also capable of loading many languages in the same request, getting the set of translated variables when first requested. Sure we can move the variable init code to language.inc so if some bootstrap code want a variable in a language, we can load that in before modules being loaded.

We need to mark these variables in the forms for the administrator to know they will be translatable through textgroups.

Sure.

$form['variable_name'] = array(
  '#type' => 'textfield',
  '#variable' => 'variable_name',
.....
);

And the form functions could take care of the default value and marking it as translatable...

It would be great if you could make this default value change (http://drupal.org/node/145164) happen in the remaining four days, so his would be workable.

The patch at http://drupal.org/node/145164#comment-250759 (or later versions when come to light) is a prerequisite, to properly support variable defaults for translation, so we can translate variables with their default values even if their corresponding forms are not saved. It also includes an elegant looking variable_get_default().

Moving to D7. The contrib i18n module already uses some textgroups for translating values at different places in Drupal.

This was a total dead end. Following the Drupal 8 configuration management initiative instead since they are redoing all of the configuration backend anyway. It is going to be fixed in other ways, so not marking won't fix.