Playing with Drupal 6's multilanguage support

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

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

This is not very exhaustive, but for most of us it was a first look at Drupal 6. Great new installer, by the way. Anyone, don't be afraid to try this stuff, it's so easy to install!

Patches that were tested:

Usability / User Interface

  • Once the translation module is activated, it would be nice if a couple of other options could then be set:
    • First, the Language negotiation settings should move from 'None' to 'Path prefix with language fallback' (the third option), as this seems to be the best option for a true multilingual site. Activating this option also activates the users language setting option. [Issue]
    • Second, the English language should be given an 'en' path prefix. By default it has none. [Issue]
  • The help text of /i18n/admin/build/translate should contain a link to /i18n/admin/settings/language
  • The "Text group" section on /admin/build/translate/import is not user-friendly/comprehensible... perhaps it would be clearer if there were other options.... but as it is I can't figure out what that really means.

Language Switcher block

  • This block only works when you select either of the two path prefix options in Language negotiation. We didn't test it with the domain prefix options. [Issue]

Node Translation

  • There is currently no way to see which node is the "source" (maybe it could be shown in /node/*/translate). [Issue]
  • Looking at what is shown under the Translate tab, there's no clear indication that a translation needs to be updated, even though it can be marked as "updated" in the node edition page. [Issue]
  • Would be nice: A way to select an existing node as a translation. [Issue]

Custom Content Type Translation

  • User created "Title field label: " and "Body field label:" not translatable. I understand that user contributed content is not supposed to end up in the localisation table but we do need some way to translate this stuff... otherwise users are forced to created different/analogous content types for each language. Note that the "Name" of the custom content type is entered into the localisation table.

Site Information Translation

  • Even after applying the dynamic translation patch ... the site infomation doesn't seem to be translatable via the usual method (i.e. enter into using interface in one language... switch interface language and translate the fields)

Contact Form Translation

  • There is no (visible) way to translate the contact forms.... This is similar to the Site Information translation... Previously this was resolved by adding the 'contact_form_information' to the $conf['i18n_variables'] array.

Language Negotiation

  • Turning on the "Path prefix with language fallback" on /admin/settings/language/configure breaks the "home" links in breadcrumb: < front > is tagged onto the end of the link, making it invalid. [Issue]

Comments

playing

Gábor Hojtsy's picture

Thanks for the review! It would be nice if you could pour the feedback to the relevant issues, so they will get to the places where they belong. Some feedback:

Usability / User Interface: well, please submit your first chunk of comments on the node translation issue, let's see what others think. The help texts definitely need an update, some our outdated. That will be fixed after the code freeze, once functionality settled. The "text group" section is supposed to be understandable because on a stock Drupal site, you would have at least "site settings" and "content types" text groups by default additionaly to the built in textgroup there now. That would only happen if people review the dynamic object translation patch, and we manage to get it in. Time is tight.

Language Switcher block: please comment on the issue.

Node Translation: this is important feedback, which should be posted on the issue.

Custom Content Type Translation: this is only going to happen if the basics on dynamic object translation are settled. There is no such functionality yet, so it is no surprise that you don't see it.

Site Information Translation: see the previous point.

Contact Form Translation: see the previous point.

Language Negotiation: this is a bug, would be nice to submit a new issue.

Thanks for these directions!

David Lesieur's picture

I'll try to dispatch all the comments where they belong!

Done

David Lesieur's picture

For convenience, I have added [Issue] links next to each comment in the original post.

Most comments I did not post an issue for depend on the dynamic object translation issue being resolved.

thanks!

Gábor Hojtsy's picture

Thanks for the feedback again!

Language Switcher block Case Study / question

SubZero5's picture

Say you have done a en/about page.
And you went thru by translating en/about to fr/qui and de/wer respectively... :)

What will happen if you are at the page de/wer and clicked on the Deutch or Français?
What will happen if you are at the page en/about and clicked on the Deutch or English?
What will happen if you are at the page fr/qui and clicked on the English or Deutch?

The current 5.x core with i18n.module seems to fail at that point, isn't it?

try it out

Gábor Hojtsy's picture

The idea is that all clicks you mention would lead to the translated version you expect it to bring you to. If you have doubts, it is not hard to grab a beta1 and try it out. It just takes a bit of time.

Did it and tested..

SubZero5's picture

Did it and tested.. (info: en. about = fr. qui = de. wer)
I used a dns based language selection and translated an article.. http://en.abc.com/about to http://fr.abc.com/qui and to http://de.abc.com/wer

I an see the about in http://fr.abc.com and http://de.abc.com which I don't want to happen. The http://en.abc.com/about links to http://en.abc.com/qui and http://en.abc.com/wer as French and German translations.

Can't those links be moved to their own sub-domains?

thanks for testing

moshe weitzman's picture

i appreciate you testing this.

the dns based language selection is really only effective for inbound requests. changing links to use the right domain was not part of the implementation (i think). you have been able to fix this by implementing custom_url_rewrite_outbound() but i never did add the ability to rewrite the base domain. if folks think this rewriting should be possible in D6, then i will submit a patch.

awaiting a patch

SubZero5's picture

I think this must be implemented for a perfect i18n...

Not only for dns based sites that do http://en.abc.com/about > http://de.abc.com/wer, but also prefix based sites that do http://abc.com/en/about > http://abc.com/de/wer too.

It must be pretty possible because the server address is written in the domain column in the languages table. The prefix based site does have the language prefix in the language column in the same languages table. So I think this is possible with node table's language column...

I am looking forward to a patch to give it a shot...