Redoing the locale module translation web interface

Gábor Hojtsy's picture

Locale module interfaceNow as we are moving into supporting translation of site settings, content types and so on on the locale module interface, it gets extremely important to streamline the translation web interface provided. As far as I see, we have the following problems with the current interface:

  • you are presented with a big search form, which you need to first understand to get something to translate
  • search results are presented with "edit" links, so you need to click over to the editing screen for all values you need to translate
  • on the "edit" page, you get input fields for all languages, but you are possibly interested in translating more strings to one language, not one string to more languages

As far as I see, the use case of translating as many string at once as possible to one language is much more common then translating strings one by one to multiple languages. Also with site settings, content types and so on translated on the locale interface, you are not actually interested in searching in them, but going through all of them, and translating as required.

So I would suggest we move to a direction similar to how watchog (now called dblog) works:

  • you get an overview screen of values to translate with a pager
  • this screen can be asked for in a particular language, and would show form fields and submit buttons on the bottom ("save translations", "save translations and continue to next page", "continue to next page"), the first going back to the localization overview, the second advancing to the next page with saving, the third only advancing to the next page
  • simple filters would be shown on the top, refactored from the search form

How does this sound for you? What interface would you expect from Drupal 6 to translate several parts of the system? While I still would not tell anyone to translate the built-in Drupal interface with the web interface, admin defined strings have no other practical way (most admins will not have any interest in working with a gettext toolchain).

localecritic.jpg318.86 KB
localecritic_th.jpg26.59 KB


mango-gdo's picture

Hi Gabor,

Although I am familiar with Drupal 5.1, I have just installed Drupal 6.x head dated May 5, 2007 for the first time. Although improvements in User Interface (UI) are certainly possible, I find the current UI quite easy to understand. I can definitely see filtering similar to watchdog (now called dblog) make the UI easier to understand and work with.

With regard to your comment "As far as I see, the use case of translating as many string at once as possible to one language is much more common then translating strings one by one to multiple languages.", I guess it depends on the stage that you are in. If you have a fully functioning website in English and you want to translate the entire website to another language, say Hungarian, then you are right, because there are lots of items to translate. If you have just created a new taxonomy term or menu item, it would be easier to be able to create translations to all active languages, especially if you are supporting many different languages.

As haven't seen an very detailed list of the i18n plans, I am not sure if the following has been discussed already. It would seem natural to be able to create menu-item translations under Admin > Sitebuilding > Menus and taxonomy-item translations under Admin > Content Management > Categories. You create node translations at the node level, so I would also expect taxonomy translations at the taxonomy level and menu translations at the menu level. Same for URL aliases. Of course, you would still want to be able to manage all translations through the Translation Interface as well.

It's probably too much work to do, but you could also consider making the Translation Interface UI dependent on the task you want to do. The two work-flows that seem predominant are:

  • Translate all items to one other language
  • Translate one item at the time to all other languages

I am imagining something like the main Administer page where you can choose to view the modules 'by task' or 'by module'. With regard to translations, the work situations listed above seem to be the most frequently used work-flows when it comes to language translation. It might be useful to have previous and next buttons (submit translation and edit next item) on the Edit String form so that one can step through the items to be translated one at a time without having to revisit the overview page.

good ideas

Gábor Hojtsy's picture

Good ideas, we will keep them in mind. Although it is unlikely that we will deliver interfaces to both being able to edit translations of menu items or taxonomy terms on the menu item or taxonomy term admin interface, the design of the translation subsystem will make it possible to a contrib module to easily add the translations widgets there and use the API to get/set the translation with those fields.

Also, if you have good UI ideas to let the user choose between the two translation modes 'all languages at once', 'only one language', please share them!

I am still catching up with Drupal i18n

mango-gdo's picture

I am still catching up with the new multiple language system. As I have installed Drupal head instead of the specialised i18n Drupal version, I believe that my install is not completely up-to-date. Is that correct?

If there is a difference, it would be great to have a daily updated tarball available with the latest Drupal 6.x i18n head?

They have recently added Drupal 6.x head to the 'Contributor links' block which makes it a lot easier for experienced Drupal users, who are not developers, to keep up-to-date with the latest release developments. Putting the i18n head tarball in the contributor links block may also get more people involved in the i18n group as there are many users looking forward to multiple language support, but they cannot install and test it easily.

If there is a difference between normal head and i18n and there is no tarball, I will probably wait until more features make it into Drupal head and test that. Once I can play around with nodes with multiple translations, I can get a better understanding of what UI improvements could be done. And naturally, I will write up those ideas in this group.


Gábor Hojtsy's picture

While we have no tarball of the i18n repository, we continually post patches which most of the time can be discussed without installing any code. We have a wiki page, which is continually updated (sometimes more then once a day) with links to actual issues: Many actual issues at hand require close to no patches to be applied, but a little understanding of PHP.

I am not sure tarballs of the i18n repository were good to be published, we have lot of unstable modifications around, which make it harder to tell actual proposed code from experiments apart. We need to priorize our change proposals, and it seems to be certain that Drupal 6 will not be fully multilingual. Although we try to recruit patch reviewers in multiple ways, people are not too busy with reviewing our change proposals. Because Drupal 6 gets shaped in the issue queue, it is important to look what is there, and not what is in our SVN repository. If there is not enough activity in the issue queue, many of our advances might be left for Drupal 7, which would be rather unfortunate.


mango's picture

I have no understanding of PHP, but will keep an eye on the wiki page and issue queue nonetheless.

Thanks for all your quick responses.

Translation Interface Overview UI suggestion

mango-gdo's picture

Hi Gabor,

I couldn't upload a screenshot mockup here, so I have created a feature issue for the Internationalization project. It's an idea for improving the Translation Interface Overview UI and I think it ties in nicely with your filter watchdog-like approach.

Gabor - Brilliant work.'s picture

Gabor - Brilliant work.
Some things that Alex and Jose and myself have been talking about include:
1 a filter that could be added so a little 'editi' emerges next to all strings on the site so i can just browse the website and click edit when i find a string that needs to be adjusted.

2 The search needs to be nicer - the cap sensitive issue is difficult

3 Also on reload after you make a translation the form should hold you selection for the language that you are working in and what kind of strings you are looking to search.

edit all strings on the site interface

Gábor Hojtsy's picture

Konstantin Käfer did some work on this for Google SoC 2006, but I cannot find his presentation now, so you can see what were the results. That will definitely be out of Drupal 6, but a contributed module would be really nice for sure. The other two points are very good suggestions for Drupal 6 core, I hope I can get around to doing that sometime, if others will not beat me to it.