Translations of menu, taxonomy, site information, profile [#116865]

I have take a look at the localizer profile submodule provided by Troy.
It is a porting of the version for Internationalization.

I have then reviewed also the mechanism I have used to permit the translation
of taxonomy, menu and site information.

All are too complex, require too much work and every time we have to rewrite
the same code and we make too much invasive actions on the user interface.

We have already discussed the way we will follow, but I make this post
to make it more clear also to whom has not read the other posts.

I'll create a generic module that will provide the interface and the the code
necessary to translate a field in an interface : menu, taxonomy, and so on ...
It will be parametrized, so I'll create only one translation interface, and
it will use Ajax. Near every field that it is possible to translate, a little
button will be inserted and clicking it a layer popup will appear, with
a combobox where to select the language, a textfield where to insert
the translation and button to save.

I think that we can then also decide where this translation mechanism have to
be applied through some configuration options placed somewhere.
In this manner we should be able to reduce the number of modules and the code
that is necessary to write, and the support for new modules should be extremely
simplified.

Comments ?

Comment	File	Size	Author
#12	localizer_translation_interface_3.png	109.03 KB	Roberto Gerola
#8	localizer_translation_interface_2.png	110 KB	Roberto Gerola
#4	localizer_translation_interface_1.png	104.5 KB	Roberto Gerola

Comments

Comment #1

ray007 commented 7 February 2007 at 21:18

I think it really is a good idea to have such a general mechanism.
I've tried to start with such a thing, but got sidetracked, and time ...

But in any may cases it is also good to be able to translate more than 1 field at once.
Be it at by switching the locale, as is currently the case with site info, or by having a collapsed fieldgroup with translations ... so let's not retire the translation mechanisms we already have. The backend code will probably see some simplification, when we have a general mechanism in place.

Comment #2

Roberto Gerola commented 8 February 2007 at 10:03

>to be able to translate more than 1 field at once
So, you mean, a layer popup form where translate
all fields in one shot ?

> Be it at by switching the locale, as is currently the case with site info
This method change the default values on Drupal main tables, and
If you decide to remove localizer you'll see not the default values
but the latest translated values inserted.

I'll finish to fix some bugs in localizer, I'll port it
Drupal 5.1 and Drupal 4.7.6 (the patches must be recreated),
and then I'll begin to work on some prototypes, so we can
better understand what is the best solution.

Comment #3

ray007 commented 8 February 2007 at 10:25

> to be able to translate more than 1 field at once
So, you mean, a layer popup form where translate all fields in one shot ?

I mean the translation section we have i.e. for menu translation.
This obviously works only for forms with just a few input fields.
Could probably be made configurable, if we have multiple working methods.

For menu I was thinking of a mass-translations form, where you get the items and translations in a grid ... but how do you distinguish between user-made items and module- or system-provided items, which should be translated using the locale-module?

> Be it at by switching the locale, as is currently the case with site info
This method change the default values on Drupal main tables, and
If you decide to remove localizer you'll see not the default values
but the latest translated values inserted.

So ... does that mean we always want to have the english version in the original table?
Wouldn't it make our work much easier, if we restored the english values in the original tables on unintall? Or provide a button in localizer settings to do that?

Comment #4

Roberto Gerola commented 10 February 2007 at 10:50

Status	File	Size
new	localizer_translation_interface_1.png	104.5 KB

Attached a screenshot of what will be the translation interface for menu, taxonomy,
site information, variables in the next release.
Tabs with languages.
We'll use this system until Ajax interface will be ready.

Comment #5

ray007 commented 10 February 2007 at 11:03

Looks good.
How are you going to make the tabs?

Comment #6

Roberto Gerola commented 10 February 2007 at 12:37

> How are you going to make the tabs?

function localizersiteinfo_form_alter($form_id, &$form) {
  if ($form_id == 'system_site_information_settings') {
    $links=localizer_block_switchuilocale_links(FALSE, TRUE);

    $form['localizer_tabs'] = array (
      '#prefix' => '<div class="tabs"><ul class="tabs primary">',
      '#suffix' => '</ul></div>',
      '#weight' => '-20',
    );

    foreach($links as $lang=>$link) {
      $active = '';
      if($lang==localizer_get_uilocale()) {
        $active = ' class="active" ';
      }
      $form['localizer_tabs']['localizer_' . $lang] = array (
        '#prefix' => "<li${active}>",
        '#suffix' => '</li>',
        '#value' => $link,
      );
    }

    $form['#submit']['localizersiteinfo_form_submission'] = array(); // register callback
  }
}

Comment #7

Roberto Gerola commented 10 February 2007 at 16:35

Updated also the HEAD in cvs to the current development version for Drupal 5.
Begun the modules renaming to lc_.

Attached a screenshot of the new translation interface for menus.

Comment #8

Roberto Gerola commented 10 February 2007 at 16:36

Status	File	Size
new	localizer_translation_interface_2.png	110 KB

Updated also the HEAD in cvs to the current development version for Drupal 5.
Begun the modules renaming to lc_.

Attached a screenshot of the new translation interface for menus.

Comment #9

Roberto Gerola commented 12 February 2007 at 13:14

I have added also a mechanism that disable the form controls (radios, checkboxs, selects)
that are not translatable, to avoid confusion for the users.

I have some doubt on using a tab for each language.
If you have a site with 4/5 languages, the interface can become
too full.
The cleanest option could be to have a select with the list of the languages
and a button to change the language.
Comments ?

Comment #10

ray007 commented 12 February 2007 at 14:43

I have to think more about the userinterface, it probably also depends on the number of languages you have.

The labels of the select-options probably should be translatable, just not the values.
If that's doable ;-)

Comment #11

Roberto Gerola commented 12 February 2007 at 15:04

>The labels of the select-options probably should be translatable, just not the values.
>If that's doable ;-)

Yes of course.
I have not yet updated the cvs, but the method :

function localizer_disablecontrols(&$form, $enabledcontrols)

will permit to disable all the controls on a form except the controls
listed in the array enabledcontrols.

It will be more clear when I'll update the CVS with the code :-).

Comment #12

Roberto Gerola commented 13 February 2007 at 13:12

Status	File	Size
new	localizer_translation_interface_3.png	109.03 KB

I've implemented a switching block with a select and a button.
Take a look at the screenshot if you are interested.

Comment #13

ray007 commented 13 February 2007 at 13:20

Screenshot looks good, I'd maybe call the button "switch", but that's a non-issue.

Question: if you use this language changer, do you switch language for site-viewing too, or do you only get the form you're editing (site information in this case) in the chosen language? The latter being preferable I think?

Comment #14

Roberto Gerola commented 13 February 2007 at 13:31

>I'd maybe call the button "switch", but that's a non-issue.
Ok, this isn't a problem.

>do you switch language for site-viewing too
Yes.
The user interface language is changed.

>do you only get the form you're editing (site information in this case) in the chosen language?
>The latter being preferable I think?

It could be done, but would be more complex, not impossible.
We should add another temporary language variable in session
and use to drive this translation interfaces.

I've update the CVS HEAD.
There is also the function that produces the tabs interfaces, if you need it.

Comment #15

Roberto Gerola commented 13 February 2007 at 15:37

>Question: if you use this language changer, do you switch language for site-viewing too,
>or do you only get the form you're editing (site information in this case) in the chosen language?
>The latter being preferable I think?

I have thought on your proposal.
It has more sense than my solution.

I have to find a generic way to implement this behavior
so that it will be reusable in others contexts.

Comment #16

ray007 commented 13 February 2007 at 16:21

Hmm, maybe start by giving localizervariable_save_variable() a 3rd paramter for locale?

something like

function localizervariable_save_variable($name, $value, $loc = NULL) {
  if(is_null($loc)) {
    $loc = localizer_get_uilocale();
  }
  db_query("DELETE FROM {localizertranslation} WHERE object_name = 'variable' AND object_key='%s' AND locale='%s'", $name, $loc);
  db_query("INSERT INTO {localizertranslation}(object_name, object_key, object_field, translation, locale) VALUES ('variable', '%s', 'value', '%s', '%s')", $name, $value, $loc);
}

And maybe make the insert conditional on a non-empty value?

And a (global?) variable $edit_locale for editing the variables for a locate other than the current?

Just starting to think about it too ...

Comment #17

Roberto Gerola commented 13 February 2007 at 16:26

Well, yes, this isn't the biggest problem.
The problem is to pass the preferred language to the same interface through an url.

At now the combobox is filled with urls of the type /switchuilocale/...?destination=
that set the ui locale in session and proceed to the destination.
Probably we have to implement other path similar to switchuilocale to set
this admin interface language.

Comment #18

ray007 commented 13 February 2007 at 16:40

We need the additional language only when editing some values, and then we have a form where we can store the value. No need to change the language for the whole admin interface in that case. Maybe store the value in a session-variable too.

Or did I miss something?

Comment #19

Roberto Gerola commented 13 February 2007 at 16:45

> Or did I miss something?
No, you are right.
But we need a method to set this language in session
and then reload the same interface.

Comment #20

ray007 commented 13 February 2007 at 17:01

I don't understand. Isn't the select-box we see in your screenshot to choose the edit-language?
Setting and reading session-variables sure isn't the problem.

The question then probably is: do we reload the whole form with the new language, or do we load the values for the other language with ajax?

Comment #21

Roberto Gerola commented 13 February 2007 at 17:41

>Isn't the select-box we see in your screenshot to choose the edit-language?
Yes.

>do we reload the whole form with the new language
Exact.

Not yet ready for Ajax.

I'll try to write some code this tonight. So it will be more clear.

Comment #22

sun

German

Karlsruhe

commented 9 April 2007 at 03:13

Status:

Active

» Fixed

Comment #23

(not verified) commented 23 April 2007 at 03:19