Internationalization

Now 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).

Now we have language for nodes -Just committed to Drupal core!!! Also, on a different thread we are exploring possibilities for a Drupal/CiviCRM multilingual soluction. So lots of things are going on, pieces are fitting together, but also it's maybe a good time to think a bit more about the 'overall strategy' of this Drupal multilingual enhancement!

I was thinking through dynamic variable translation with Konstantin Kaefer yesterday, and some good ideas come to me after I gone off IRC. This could solve variables, content types, menus, taxonomies, blocks, user profiles, as long as we add dynamic string based translation to these (which will be possible to turn off by type :).

1. We cannot reuse the locale functionality, because it is designed for "static English string to static foreign language string translation" from the ground up: http://groups.drupal.org/node/1827

2. We cannot use a simple t() like function either, as we need special widgets with validation and submit functions for some values (like the site logo or default user picture).

3. We cannot reuse the admin interfaces (menu, taxonomy, content type setup, settings pages) as localizer does, because many sites will not give administrator, menu editor, taxonomy editor, content type admin or site setting admin permissions to translators. BUT we need to reuse some forms from there.

4. Dries would like to see a simple reusable API anyway :)

So, we need to somehow get together what is good in t() and what is missing from t(), as well as provide a specialized UI for translation of these strings, a one-stop-shop for dynamic interface translation for the user.

Jose Reyero just completed updating the handbook “Internationalization: Building multilingual sites” on Drupal.org to reflect some of the new developments with i18n and Drupal 5.x. This new documentation makes it easier to start using i18n and to understand all the new features and fixes that both Jose and Gabor have been helping move forward. It even includes screenshots to show off some of the latest features added to the module.

It is a great place to start if you are looking to see if i18n will fit your needs and should save you a lot of time during basic set up. I know a lot of people new to i18n are coming to this group to see the latest on the module and would like to know more about what is happening right now with drupal 5.x, so I will try to post more often here with user end perspectives.

We are currently working on adding language support to nodes in a simple and clean way. Meanwhile separate implementation details and issues are now created and discussed in the issue queue of our project. Feel free to comment on our implementation and/or submit patches as we move along.

Drupal 5.x and before has a "locale" concept, which lets a user see the interface of the website in a choosen language. The list of available languages for locale is defined by the administrator, and a user can choose a preferred language on the user profile editing page. It is only possible to translate the built in interface text though, and none of the admin specified text (ie. site name, site slogan, menus, categories, blocks, etc) is translateable. It is also not possible to translate content sent in by different users of the website.

Some solutions evolved through the years to overcome this limitation, making it possible to translate user defined interface and content elements. Unfortunately these modules only build on what is available in Drupal and are not as closely tied as some performance requirements or design considerations would require. Since the Drupal core code is not ready to handle this situation, most contrib modules don't care about offering this feature, and internationalization (i18n) modules need to work around them too.

In getting ready to add support into Drupal 6 for better internationalization, we examined the code base of the available modules (although these are actively changing), identified the problems, looked at the possible outcome of some development around custom node types, menus, etc. The summary bellow is a list of items we worked on last week in Budapest and reasoning behind some implementation details.

The first implementation detail we are looking at for Drupal 6-dev i18n is abstracting language settings out of the locale interface. In Drupal 5, the locale module handles the list of available languages (which is reused in i18n related contrib modules). The data stored about languages is not enough for most purposes (native names are not stored, RTL-LTR direction information is not available), and extending modules really have no way to plug into the language management screen.

The point of this post is to do a round up for the community, get on the same page with some of the developers, and find a path toward what to do for Drupal 6 core and beyond, as well as with contributed modules.

The most abstract concept in my opinion: "everything is a field" (fully atomic value) instead of "everything is a node". CCK is ardent proof that this idea could work. If that's the case, we can share the same field (as regards value), node is just a set of fields tie together by new relationships system, whereas content type is a predefined set of relationships between fields.