Internationalization

Is there a way to automatically wrap all "translated" text with html tags? For example, the font for dz (Dzongkha/Tibetan) is really quite small compared to western fonts due to the possible height of characters in the language. It would be very useful to take any text and wrap it with tags so that I could then institute text formatting with a stylesheet, while not disturbing and western text that may be untranslated.

http://www.nooku.org/

First post here in this group, so a warm "Hi!" to everyone!

The background

I was under the impression that when selecting a language, from the language selection block (in drupal6), the content is also filtered to display only the nodes in the selected language

This behaviour is also confirmed by this handbook page http://drupal.org/handbook/modules/translation

(maybe this is not really for drupal 6.x as it states ??)

I'll add multi language by use I18N for drupal6.1 plus GUI for add multilanguage
and multiseletion use language in web.

The National Democratic Institute is looking for a creative and flexible programmer to build cool tools that help our partners around the world create more transparent, accountable and democratic governance. The programmer will work with our ICT Team and our country teams to design and build software for governments, political parties, civic action groups and networks of political reformers.

Hi!

In D5, we introduced Autolocale module, enabling users to import translations after enabling module / during installation. However, this had few caveats, as timeouts on cheap shared hosts, etc.

In D6, Autolocale is built-in core, using batch API and just works very well.

What do you think next step should be? From my point of view:

"Let Drupal automatically fetch translations from a server".

I'm new to Drupal, I am about to create a multi-language site, I had to go with D5.7 since D6 is not yet compatible with many modules that I want to use.
I've been researching drupal sites for a step-by-step guide , I found some information in drupal handbooks but I still have many questions:

• the locale module allows to translate core drupal modules and strings, does the i18n module allow to translate any newly installed modules ? or is it just about translating content (nodes) ?

I was suggested to ask here why there are string not being translated of the page node? The string that are not being translated are page; title and body. Why is that and can I override it?

Hello, we would like to release the Drupal press release in multiple languages to show case the internationalization capabilities of Drupal 6.

The press release is available at http://drupal.org/press/drupal-6.0/en

Required/pending translations:
Hindi - http://drupal.org/press/drupal-6.0/hi
Cantonese - http://drupal.org/press/drupal-6.0/yu
Chinese (Mandarin) - http://drupal.org/press/drupal-6.0/zh
Esperanto - http://drupal.org/press/drupal-6.0/eo
Gujarati - http://drupal.org/press/drupal-6.0/gu
Japanese - http://drupal.org/press/drupal-6.0/ja

As D6 is getting really close and we all try to test "everyting" I stumbled into an "old friend". This problem started up like a bug/race between the globalredirect and the i18n module. In D6 that part of i18n is moved into the D6 core, so all you need to test/trigger it, is a D6 installation and the globalredirect module. No I'm not so sure anymore, if it is a "D6 problem" and if it should be moved to D6 issues or if it still is a isolated globalredirect bug?

I just want to be sure that the path-handling in D6 is as robust as possible. Is jose also the maintainer for the "core part" of i18n? "nicholasThompson" write that he is fully booked and don't have the time to look into the issue, and that's perfectly OK, but I want to get the i18n people's attention, and everyone else involved in making international sites, and maybe there is an other way to solve it.

--
Stein Magne
http://smbjorklund.no

Hello,

Hi !

I've written a small module to mass-export nodes into XLIFF files because I needed a complete site-translation.

It exports all nodes to "files/xliff_export" creating sub-folders for each node-language.
Works with i18n and localizer nodes.
It uses XLIFF Tools module.

download here: http://ww1.peak.at/xliff_massexport.tar.gz

Alexander.

Hi Gabor et. al,

I'm starting to play with the D6 beta 3 and I'm loving it. Hopefully I'll be able to contribute something, even if only use cases and a some patch review.

I am having trouble with a locale/internationalization issue. Is this a good place to post?

Having installed D6 beta 3, I ...

a) created a story node with some text in english,
b) enabled the locale and translation modules
c) enabled imported the D5 french localization of the site (which got the vast majority of interface strings),
d) did my own special ;-) version of a french version of my story node

Copied from http://factoryjoe.pbwiki.com/FeedbackForDrupal6 so people can comment and act on it.

Please help turn the @TODOs into into tickets and patches!

Installation

• It's awesome that Drupal defaults to install.php if you haven't previously setup the site. That's a much better experience than having to know that you have to hit install.php first. Then again, it also means that you could be intercepted; unlikely but still something to consider.

Hello, we are trying to get Drupal case studies, from show case sites by Geography. North America, South America, Europe, Asia, Africa - If the sites have a cross geographic element or are internationalized then that would be even better. The goal is to show that Drupal is being effectively used around the world.

Drupal sites by Geography - Internationalization use cases

Top African Sites:

• http://www.afgri.co.za/
• Abahlali baseMjondolos - South African advocacy group

Africa

What options does one has when trying to set up an internationalized or multilingual user profile at multilingual site. When useing the core profile option the i18n module provides the posibility to translate the names of the profile fields, which might be enough for some profiles, but if you want a profile where user writes an introduction of him self, you are in trouble. Exposing the user entered text for translation trough t() function is not a good option.

The language support provided by the i18n modules Drupal 5 and (it seems) from the dev. version of Drupal 6 makes makes it easy to maintain content in multiple language versions, but doesn't seem to handle multilingual users very well.

The menu settings for a multilingual Drupal should be able to choose between:
1. Show only nodes in your default/preferred language (suitable for monolingual users and for sites where all content has been translated) This hides content from languages other than your own.

See http://blog.worldwidelexicon.org/2007/05/25/simple-localization-system-s...

SLS is, as it suggests, a simple way to localize applications and websites. The system works as follows, and is easy to implement in a wide range of scenarios. Let’s imagine that you have a web user interface that you want to make available in many languages. With SLS, you simply do the following.

Updated: June 20, 2007: RTL HTML Email now possible with my patch to the new htmlmail module.

Requirements for Drupal 6 core RTL email support - Request for comments

It has been 8 months since I've implemented a Drupal 4.7 user.module patch to support RTL emails (attached).

My next target is to ask for the RTL/i18n community help to update the code and migrate those proven changes into the Drupal 6 core. This will save tons of later headache.

Here are the basic requirements - I will need your feedback on the concept (implementation is quite straightforward).

I just started the Auto Translate project. This module, when complete, will add a button to the node translation tab that will fill in a textarea with a (very rough) translation from a third party automatic translator, such as Babelfish or Google. The module may also be configured to translate the content within a textarea.

Now that the RTL support is in core, here is a test RTL language switching on the fly.

I've installed the Language switcher patch, and activated the block - It works great - even with CSS compression tuned on. Test it now on http://dev.drupal.org.il and try to switch the language from LTR to RTL.

Update, May 31: The bluemarine RTL CSS patch has now been entered into Drupal 6's core. The dev site now displays a beta version of the next RTLised theme - pushbutton - for review (you can still select the bluemarine RTLised theme when you login). I've opened an issue Core RTL pushbutton theme is almost here - your help is needed.

Amnon

Here are some issues that have been identified during today's Montreal Drupal Meetup. This document was written collectively by some of the attendees in a Gobby session (so please don't shoot the messenger! ;-)). A wiki page seemed like the next logical step. Maybe some of these points should be posted in the issue queue (if you do so, it could be nice to edit this page and add the link).

For Drupal 6 to be able to come out with some fundamental multilanguage support changes, reviews of some modifications and improvements are needed. There is not much time left until the code freeze, but we have a list of important issues and some possibly nice additions for you to look at. Lot of the groundwork material we developed is already in Drupal 6, which makes it possible to provide some cool user facing functionality. Now it is a good time to review the suggested changes, propose corrections and help Drupal 6 to rock in the multilanguage world.

What's already in Drupal 6? A new language subsystem which supports multiple text groups to store translations in (additionaly to the built in interface translation text group available before). There is built in support for language dependent paths and domains, right-to-left written text, with some of the themes already capable of displaying RTL pages out of the box (more to come). Interface translations are automatically imported from the file system when you install Drupal or you enable modules and themes. Posts on the site can have language associated with them, and there is a simple content translation module built into Drupal.

What is left to do? Well, the following:

Translating site settings
http://drupal.org/node/155381 - The absolute minimum to support site settings translations with a contributed module

Translating content types, user profile fields, etc.
http://drupal.org/node/155047 - Minimal object translation wrapper for content type, profile, aggregator, etc. translation

Themes still missing right-to-left display support
http://drupal.org/node/148084 - Pushbutton RTL styles
... - Garland and Minnelli RTL styles

More visible language support
http://drupal.org/node/154151 - Language-aware search

Usability improvements
http://drupal.org/node/52990 - Redoing the locale module translation web interface (see http://groups.drupal.org/node/3916)
... - Define and implement Drupal 6 translation packaging format, redesign interface translation workflow (this is done as part of Google SoC 2007)

Would be nice for multilanguage features, but probably not going to happen in Drupal 6
http://drupal.org/node/147041 or http://drupal.org/node/146033 - Two different approaches for built-in site settings translation
http://drupal.org/node/141461 - Translating any objects in Drupal (it has a good UI, but the performance is not acceptable yet)
http://drupal.org/node/141419 - Rework profile categories (has many advantages, for one being able to translate categories)
http://drupal.org/node/145164#comment-250759 - Refactor variable defaults
... - Eliminate t() from $link parameter of watchdog() calls

This is an old issue, and I wish to get a clear up-to-date status of the situation in Drupal 6 (or 5). It may have been answered already, so a redirection would be as good as an answer :-)

1. RTL CSS files in core: In order to ease the RTLization of themes, and to set a nice example for themers and module developers, core modules should come with and RTL version of CSS. Such a set already exists, and is used in every hebrew Drupal site, and surely in other RTL languages sites as well.

We have posted a patch to support object translation of certain Drupal objects (content types, user profile fields and categories, site settings, and so on) to multiple human languages. While we have clear concepts and very good ideas for the user interface (which we though before that would not be easy), performance-wise we are at crossroads. We would welcome beginner as well as expert reviewers to come and share their performance ideas about Drupal object translation, so Drupal 6 can include a mature translation infrastructure, advancing ahead of the competition. ;) We need your input!

"Introduce dynamic object translation API (optimize this!)" http://drupal.org/node/141461

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

Because there does not seem to be active development around the JavaScript localization issue, I figured I'll try to get some attention from the Javascript group. The issue at hand deals with enabling string localization in JavaScript files. Because Drupal 6 will be a big push in the multilingual direction, localizing JavaScript files should also be actively on the table. If you have time, please look into this patch or at least drop in your two cents. Thanks!

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!

There is some concern that pathauto's i18n integration isn't functioning properly. I don't understand it or have the interest to work on it. So, I'm writing here to say:

1) If it's agreed that nobody has it working, I'll remove it so we don't confuse people about totally buggy code. Please respond either here or in that issue if you have a feeling about that.

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.

Things are looking good for a strong multilingual Drupal 6! A lot of good work has already been knocked out, and now we need people to start testing the current codebase (svn repository) and to provide feedback on how it works. Please post comments here or on the issue tracker .

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.

By looking at what people described as their use case, there is a considerable amount of interest in a CAT (Computer Aided Translation) support tool in Drupal. While Drupal 6 could (and will by default or with a contrib module) provide a translation interface for nodes, content created in professional systems is often not translated inhouse, translation work is outsourced to professional translators. These professionals employ tools to remember previous translations, build on existing terminology and reuse what is already done. The industry standard for data interchange with these tools is the XLIFF format, for which fortunately Bryan Schnabel developed (and released under GNU GPL) some XSL transformations I was able to reuse.

All this resulted in the first implementation of XLIFF Tools, a module to export and import XLIFF data of Drupal nodes. I have tested some basic content nodes with Heartsome's XLIFF Translation Editor, and everything seems to be working smoothly, but there are probably hard edges you will be able to find if you try out this new tool. A development snapshot for Drupal 5.x will be available as soon as the build system generates the tarball.

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.

The first (quite big) patch coming out of our efforts is now submitted for consideration. Dries Buytaert already reviewed a big part of what I submitted today, so I hope the submission will result in a fast and satisfactory result (although the upcoming conference in the coming days might delay the submission of the patch). If you are interested in the language functionality developed here, please look at the patch, try it out, provide your comments!

Update: And the patch got committed after thorough reviews from multiple developers! Yay! On for more work!

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.

Seems like we have not communicated the infrastructure we use to create and test the actual code changes properly, as we get questions about the process frequently.

• Development Seed sponsors a subversion repository, where some people already have accounts to commit changes. The server is open for anonymous checkouts, so anyone can try out our changes as we go along. The web interface is at http://svn3.cvsdude.com/vvc/devseed/i18n/?root=sandbox There we have a temporary fork of Drupal, which we periodically sync with Drupal 6-dev. We already use some of the fruits of the 6-dev branch, like the url() and l() related changes, and we build on the new menu code. Since what is in the repository is a full Drupal, you can try it out, set up, test and benchmark. Use this subversion root: http://svn3.cvsdude.com/devseed/sandbox/i18n/
• Every commit to this subversion space ends up on the internationalization at devseeddev.com mailing list, which has a public archive and is open for participation. You can subscribe or view the archives on the web interface. This list is intended to be for code level discussions involving the i18n for core project (and is definitely not a support or discussion channel for any existing contrib modules).
• As we go along, we document our changes and the reasons behind them. Expect some documents to come the next days about the development sprint we recently had. Our final goal is to get Drupal 6-dev ready to accommodate i18n related needs, and for this to work, we need to create smaller patches out of the repository we work on now, once some implementation seems to be feasible to get into Drupal core. Until changes get into the official Drupal 6-dev, we are more than open for your suggestions, benchmark showing that there are better ways to do the implementation, etc. (This is also possible after patches get into Drupal 6-dev, but then you need to persuade the core maintainers).

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.

Hi All,
I've posted the idea of a session on internationalization here on the OSCMS/DrupalCon CA 2007 site http://2007.oscms-summit.org/node/92

You can vote for the presentation and add comments to it over there.

cheers,
Ian

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.

"Relationship" I understood as relationships between fields (nodes are many relationships, which are subject of more advanced process).

Wanted features:

1. Powerful and without limitation thanks to the most abstract (see: "everything is a field", compare this to: Global CCK fields, A controversial(?) point: store translations as nodes).
2. Build-in categorization features.
3. Build-in views features (listing fields, not necessary nodes).
4. Build-in menu features.
5. Support for Semantic Web/Microformats/similar.

Observations about current situation:

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.

Development Seed sponsors the Drupal 6 core i18n development, so we can collaborate on feature development and keep up with Drupal core changes at once. The basic idea is that we need to (temporarily) fork Drupal, so that we can make changes to the core ourselfs, test the code we add and also provide it for others to download and enjoy (ie. fix bugs).

Since these kind of forks (CVS branches) are not technically supported by the Drupal infrastructure, we needed to look elsewhere (but not too far) for a sponsor. Development Seed already sponsored the i18n module efforts by Jose and they offered support for the Drupal 6 core i18n movement at the DrupalCamp/GovCamp meetings in September, so they were a natural supporter.

Although actual implementation details are still forming around the pieces we are trying to implement for the Drupal 6 core i18n feature set (which will get shipped with Drupal 6 hopefully), we should define some goals which we aim for, so we see the target. Unless we work in the same direction, there will be no useable consistent i18n solution in Drupal core for people to build their sites on. So what is possible to accomplish in the Drupal 6 timeframe, and what will only be possible to implement in contrib modules?

As a follow up on Gabor's post, I fully agree with, String translation: why using t() for user specified text is evil, I'd like to introduce some idea about how we could have web configurable translatable texts.

Instead of reworking all modules providing web configurable field names, descriptions, etc... We can handle that strings having an unique id for each string with minimum changes for the modules. How? Please, read on

Instead of storing in the main tables these translatable texts, we can have stored only an unique id, like 'profile_field_title_xxx' or 'flexinode_field_description_xyz'.

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.

If you look at the existing implementations I reviewed, you see different methods used to allow you address content on your site with a URI. The most requested feature (which was implemented in tr.module and is somewhat implemented in localizer) is to be able to use different hostnames for different languages. Let's see the good and bad of all the options used.

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.

Let's see what options do you have, if you intend to set up a website with content translation using Drupal. Clearly the i18n module comes into mind, but if you start to look deeper, you will see more approaches tried in the past and in progress, some of which might have very good ideas to carry on. I have actively tested and code reviewed some modules to see what are the options, so we have something to build from, when thinking about i18n support for Drupal 5.0.

To sum it up, all of the modules tested have weaknesses, and there are some striking common approaches (some of which are clearly not desired by some community members). We should discuss some basic approaches, so we can build on them forward. Discussion points will follow in different nodes in the internationalization group.

In case you find any errors or omissions in the comparision table, feel free to point them out.