i18n

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

Since I know internationalization is a big deal to Canadians, I figured I'd cross-post this to some groups. Please don't kill me, this is important. :) There's very little time to get these patches in before code freeze! (June 1)

The following patches desperately need reviews from people familiar with internationalization of site content. The goal is to get Drupal 6 to have internationalization right in core:

<

blockquote>
- translation of site settings, content types, user profile fields
and so on by storing translations of their string properties with

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

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

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?

Steven recently got frustrated enough with the Drupal core restriction on international letters in path module that he removed it..

So, now pathauto and urlify can use any character from the node title that the user submits.

I've created an issue for pathauto to see how to best handle this. Please provide your input on the ideas there.