Support for variables: new module, localizervars.module

Thank you very much.

But which version are you using ?
Can I ask you to use the latest cvs version for writing patches ?

The code in your patch has been already changed.
It seems to me that the code patched is a bit old.

Download from the cvs the sources with the tag DRUPAL-5,
if you want to contribute.

Thanks again.

For a variable, because we have to translate only its value, it would be sufficient to use :
localizer_get_objfieldtr($object_name, $object_key, $object_field, $locale)
or
function localizer_get_currobjfieldtr($object_name, $object_key, $object_field)
to read the value in the current locale.

The variables are stored in global variable $conf.
We need also a configuration section where to specify which variables
need to be translated.

Thanks

Thank you very much for your effort.

I'll take a look to you code during the next weekend and hope to be able to integrate it
very soon.

I have to check the cvs because the function you are patching it seems to me
a bit old. I'll try to download the sources again from the cvs and I'll verify
they match with my development version.

This is the last cvs version of localizer.module file for branch DRUPAL-5
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/localizer/loc...

As you can see the definition of the function has been already corrected some time ago

function localizer_get_objstrs($object_name, $object_keys) {
  $translations = array();

  // skip empty requests
  if (empty($object_keys)) {
    return $translations;
  }

  $string_keys = "'" . implode("','", $object_keys) . "'";

  // get translations
  $result = db_query("SELECT * FROM {localizertranslation} WHERE object_name = '%s' AND object_key IN (%s)", $object_name, $string_keys);
  while ($tr = db_fetch_object($result)) {
    $translations[$tr->object_id][$tr->locale][$tr->object_field] = $tr->translation;
  }

  // or an array of translation sets for multiple items
  return $translations;
}

I have taken a deeper look to your code for variables support.
It is a very good start point. Thanks.

As user I don't like to specify the variables to translate
in the settings.php.

I think that perhaps the best solution would be to prepare a translation
interface similar to that used for menus.
I mean, something like this : http://www.speedtech.it/files/images/localizer_menuitem.png
but implemented in the general settings page.

I would like also to integrate the proposal of Ray for this type of translation interfaces :
http://drupal.org/node/111773

I think we have to subsitute the init hook with the menu hook, otherwise
we could encounter some errors on some installations.
Take a look here :
http://api.drupal.org/api/4.7/function/hook_init

This hook is already present in localizermodule.
I'll add you code there, so we have an unique place
where all the initializations have effect.

Let me know what do you think !

>I think it will make the settings page really huge.. and you'll need to check variables size/type to generate translation fields.

Yes the size/type would be hardcoded, but also the variable on settings page are fixed and hardcoded.
Simply a fieldset collapsed.
The best way would be to have a tabbed interfaces.

>May be you can suggest better way? I think it's the most flexible way for now.
Yes. An interface under localizer settings where the user can select which variable he/she want to translate.
And also a generic management console where the user can manage all the translations of all the variables,
menus, taxonomy and so on.

Yes, absolutely.
It should work like the switching block.

I'll take a look at the Forms API to see what we can do.

I've taken a look also to Ray patch for menu.
It goes in the same direction you propose : switch language and you can insert the translated strings.

So, I think that I'll follow this way.
It simplify the interface a lot and reduce the confusion for the user.

We can work on the menu input filed on node page in the same manner :
"overriding the input field".