Internationalization

There is a strong stream of support for using the Drupal built in t() function to translate taxonomy terms, vocabulary names, menu items, profile field titles and options, poll titles and options and similar user specified content. This is a very bad practice, and should be changed. It should be pointed out that this system is reused, because it is ready and seems to be easy and fitting for the problem. Unfortunately it is neither easy, nor fitting. Let me explain why, and where should we look for a solution.

A striking similarity of all examined content translation modules is that they store translated content as separate nodes. Some of the vocal members of the community expressed their concern about this solution, refering to 'content duplication' as a problem. I suggest that we should store translations as their own nodes, but it does not mean we would not be able to solve any of the problems raised. Let's see what are the disadvantages of storing translations as nodes, and what do we get as an advantage.

I am a web architect and a system analyst. Now, I've translated Drupal To Hebrew and initiated the creation of a drupal community in Israel. Following Gábor Hojtsy's request, Here is a use-case analysis of my expernece from the Hebrew Translation of Drupal, and with it's implementation on tens of sites, with indexation for search engine relevancy.

Recently, I've tried the Internationalization module on two of my sites, but gave it up and decided to wait for a later time. Problem is that i18n is not yet compatible with many other modules. I am a heavy user of taxonomy / category modules. The i18n module is a big step forward, but more work is needed. I need language specific taxonomy with menu integration. On one site, I have tried to use the taxonomy module, but found that the vocabulary names are not translated (nither in the node entery screens nor in the menu). On the other site, I tried to use the new category module but discovered that the node input form (and the menu) displayed all categories without language distinction.

You have set up a website where multilanguage content submission and display was a requirement? What was the workflow specified by the customer? How were relations between different languages defined? Did you have all content translated? Was translation into specific languages a requirement for publication? Did you translate all navigation and even site level images? What was special about that project?

An internationalization use case consists of the requirements you faced, the user workflow you needed to support, and the interface you provided to the user. We are not interested in dirty implementation details (modules, PHP code, CSS) at this stage, only higher level information about how you built up multilingual content, interface, navigation and site design. You don't even need to talk about Drupal projects. If you have any other use cases to share, which you experienced out of Drupal, we are interested. The goal of the above questions are only to start you up, don't let them stop you from sharing your story in greater detail.

You can either post a new story to this group or comment on this story with your use case. Thanks for sharing!

The goal of this group is something that we should define up front. When I write this text, Drupal 4.7.x is stable, and we are going to release Drupal 5.0 in a few weeks. Still Drupal 5.0 is only going to have interface translation services, supporting the display of the built in interface strings in different languages. There is an i18n module addon however, which is badly needed.

The goals of a truly international site are actually much wider then just interface translation. One needs to translate user defined items like menus, the site slogan, titles of custom blocks, even the site logo image. Whenever you start adding content to the site, you might want to add it in different languages. Sometimes you might need attachments from one post in the translated one, sometimes not. You might even need calendars to adapt to monday or sunday starting a week with different languages. All these issues need to be solved, and new issues will come up along the way. The goal of this group is to come up with questions, and ensure that we find adequate answers for them.