To cater to the needs of multilanguage websites, Drupal and other content management systems should take into account the different uses of these sites and the unique content and interfaces they provide. For example, a search site where content will not be translated might need different languages in its interface, while a personal blog where posts are entered in different languages might need many different features.
I asked the Drupal community to tell me the use cases they used in internationalized websites in 2006. After going through this data and filtering the comments, I have identified the following practical use cases for websites built with an English-based system, such as Drupal, but that may also support foreign languages.
English (Factory Default) Only
This is the simplest use case. In fact, it means that the English "factory default" text can be used in the project and that English content is posted. User specified interface text is in English. This monolingual scenario is the simplest, and is always supported in every system.
English (Customized) Only
When one needs a customized English language website (different site design or different wording to account for U.S. and British English differences or stylistic requirements, for example), it is still quite close to what the system provides by default. User specified interface text is in English, and only some text and design elements need to be changed. Drupal makes this possible with the locale module, which is often suggested to be used to make arbitrary text modifications for stylistic reasons. Drupal 6 includes some optimization for this use case, letting site administrators include a short list of customized strings in the settings file and use that without the locale module.
Single Foreign Language Only
This monolingual scenario occurs when a website is built with a particular system, but the factory default language is completely replaced. This case requires that the interface text be completely translatable and that the language of the resulting site be configurable so its web pages show the correct content and the proper language code. Also, user specified interface text must be given in the actual language used. Drupal 5 supports this scenario with the locale module but does not give content the proper language association. This is improved in Drupal 6 with some performance improvements for single foreign language sites and content language associations. Multiple Interface Languages Only
On a photo showcase site or website that pulls external data (like a search engine or news aggregator) where content is not a target for translation, it is common to present the interface in various languages. Users should have the ability to choose their desired interface language, and the system should be able to choose a reasonable default for users visiting the site for the first time. Additionally, user specified interface text should be given in all languages used. While Drupal 5 can provide multiple interface languages with built-in features, automatic language selection is only possible with modules such as i18n. This feature is, however, built into Drupal 6.
Multilanguage Content on the Same Site, but Not Associated
Multilanguage blogs and international community news sites are typical examples of websites that require the posting of content in multiple languages. However these posts remain stand-alone pieces that are not connected to each other (as translations of the same content are). In this use case, content needs to be marked as being in a specific language and selected from multiple languages. The interface should be available in the same languages so that user specified interface text is given in all languages desired. This functionality is supported in Drupal 5 with modules such as i18n and built into Drupal 6 with enabling the locale module.
Multilanguage Content Implemented as Sub-Site
Many big international companies have regional sub-sites for their local businesses. However, these sites use a slightly different page layout and design elements, and often have a distinctively different structure of pages. For example, these sites do not require the ability to jump to the driving directions page for the German office from the driving directions page of the French office. Additionally, there is no requirement that both pages exist and are in a similar content structure. This kind of site design allows for the best local adaptation but does not allow content to be related between sub-sites. In this use case, user specified interface text is managed uniquely on all sub-sites. Drupal's long time built-in multi-site features make this possible. However, Drupal 6 supports different domains for different languages, which allows for translation associations if needed and offers a smoother transition between the different models.
Multilanguage Content with Translation Association
The most complete approach to multilingual site building is to have copies of the same content in different languages that are linked together so the system can show users a default version and users can select a translation if desired. In this use case, the system can show the appropriate interface for the content language desired. The main challenge is that if content is not available in the desired language, there is no direct answer as to what should happen: a fallback to some other language, an error message, or a redirect to a search page are all possibilities, and ideally a system should support different approaches. This design allows site administrators and content authors to use complex workflows too. For example, translations of the same content can be monitored for timeliness, and multiple language versions of the same content can be required to be written before a text is published. User specified interface text should also be given in all languages.
Drupal 5 supports some of these needs with modules such as i18n, and Drupal 6 has most of the basics built-in. Complex workflows will be possible with the built-in actions module and the contributed workflow module, and translation associations will be supported with the translation module.
Technically speaking, the sub-site method actually has no multilanguage requirements and as a result, workflows and permissions are not related to available languages. This is often a practical way to side-step issues with multilingual content handling but results in a weak user experience and uncontrolled editorial flow. It should be noted, however, that any of the site types involving one or more content languages or at least one non-default interface language require internationalization. Naturally actual web projects often move between these models, so a system, such as Drupal should support seamless adaptation to the chosen type of site.
While Drupal 6 (soon to be released in beta form) will still need contributed modules for complete multilanguage support, development on these core features will only continue in Drupal 7.
This post was originally published as a guest post on the Development Seed blog. It is not available there anymore, so archived here for posterity.