drupal core multilanguage - locale
http://drupal.org/handbook/modules/locale 6.14
updated Fri, 10 Aug 2012 for drupal 6.25
Multilanguage introduction:
Setting up a multilingual site is not done 1-2-3. As far as core multilingual modules locale and content translation go, they are fine, but they don't take care of all content. The i18n module fills this gap, yet it is also undergoing further development. At the same time not all contributed modules are adapted to fully use multilingual functions out of the box.
Main function:
Locale allows you to add and manage languages and translate the built-in user interface.
Example function:
You want you use more than one language on a drupal web site.
How to: Adding locale language functions:
Enable in Suite building > Modules > Core-Optional: Locale
Set role permissions in User Management > Permissions for locale module: administer languages, translate interface.
Site configuration > Languages > Add language. Choose a pre-defined language. There will be an import of something. The UI jumps to List, the new language is now listed. Here on this list page, click edit for the new language and check the settings. You must either use a Path prefix (ex: domain.com/nl) or a Language subdomain (ex: http:nl.domain.com). I (for my specific case) choose Language domain, remove the entry for Path prefix that was entered by default and fill the Language domain such as http://langsub1.domain.com. Note that this domains needs to have been set up, and be functional beforehand. If needed, I do the same for the original language to what it needs to be for these settings. Note: I haven't made the new language default yet. By the way the language switcher is not yet showing.
Site configuration > Languages > Configure. I'm setting for domain only, as planned. It appears that this will not browser detect. (The setting Path prefix with language fallback appears to browser detect, according to the on-page help text (and elswehere)).
Site building > Blocks > [Theme name]: Language switcher. Click the Language switcher block's configure link to adjust user visibility, role permissions and page visibility. Save. Back on the blocks page, make the block visible on-site by selecting the location for the block. Click sSave at the page bottom to ensure it's positioned. To see the actual block, go to any page but the blocks page! 555.
This final step has made the language switcher appear. And I'm beginning to see the admin interface sprinkled with unintelligible second language words here and there. At the moment it's still within limits. Also, while the second language uses the same template, the font appears differently, actually too fine for English (note for example, these non-latin characters: ຂໍຕ້ອນຮັບເຂົ້າສູ່ ວິກິພີເດຍ. Nice that Drupal's UTF-actually does display this! These characters do look hazy and probably do require a finer font. And inversely, content texts are showing practically in bold. Anyway, English in the second language will be temporary.
Finally, I take a deep breath and change the default language to the newly added language:
Site configuration > Languages > List. Mark the Default radion button for the language to be defaulted. Click Save configuration at page bottom. Voila.
As a side note, instead of Default I actually marked ค่าปริยาย, blindly trusting my instincts. I really do wish that drupal would give the option to leave the admin section alone when switching to another language.
Still on track. Now let's add Content translation.
Language paths:
The language negotiation paths need to be given some serious thought. Of course the path prefix (ex: domain.com/de) is the obvious and easiest solution. It has a number of pro's and con's. The alternative, language by domain (ex: de.domain.com) has pro's and con's as well, and is a bit more complicated to set up. More about this another time.
Language detection:
Language detection can auto-direct the user to the appropiate site language. It is usually based on the user's browser setting. By drupal design, language detection and auto-direct works only when the site's language negotiation is configured with path prefix (ex: domain.com/de). The specific setting is Path prefix with language fallback, in Site configuration > Languages > Configure.
There is no auto-direct option when language negotiation is configured with domains (ex: de.domain.com). Not quite sure why this is so. Problem is, I think I might need it.
On-page language switchers:
These will automatically activate once a page is set for a specific (real=not neutral) language. No role based persmissins can be set for these. They can only be turned off by installing the internationalisation module (i18n, which has a checkbox for this). You will most probably need it no matter what (for blocks, menu, content string translations...). It's important to consciously decide to use these or not.
- are they needed for users? probably not
- can they cause search enging confusion? probably yes
- if Site configuration > Site informaiton > Default front page is defined, the language link may represent duplication risk (at front page level), that is not good
- i18n: if only the on-page language switcher (checkmark - content translation links) could be given role permissions, for example, for an admin or translator role.
As it is, I am turning them off with the i18n module, and also restrict the language switcher block to the self-admin and translator roles. I am treating the languages as separate sites, hence the domain separation. At the same time the design and content is kept identical (as far as possible).
I'll go into the i18n module next.
Small problem:
Initially I installed the site in English, in order to assure an English interface. As the site is both English and Asian, and located in Asia, I switched the default language to the Asian language, before doing any translations. I had read that doing may break strings translations, so I didn't do any translations yet. After installing i18n and working on the menus and blocks, the problem manifests itself: it looks like the string translation system is confused:
I see only one language as result in the translation strings, the Asian one. It always appears with strike-through, that is untranslated, while translations have been made. There is no "en", or strike-through "en" at any time:
- Searching with English terms, I only get results if searching All languages, no results for searching English and no results for searching the Asian language.
- Searching with the Asian language terms, I get results for All languages, search results for the Asian language - and search results for English. This is super, super bad. Then, menu or block string translations do not show up in English.
It looks like it is treating its own default language as the "foreign" language and English lnanguage has somehow somehow become undefined.
I have a sinking feeling that I'll need to start all over again. Time to leave this stuff behind for a while. -)-)-)
Confirmed. Since I have nothing to lose, I switched the default language back to English. Yes, the search results still show the Asian language as target translation language in strike-through. At least this is correct now - but it means a) I may need to scrap the site and b) there is something wrong with the system's logic when I earlier switched the default language to Asian, but it would not switch the translation functionality, which strangely remained in the Asian language - apparently translating to English but defined to Asian?
Workaround:
Interim conclusion: With default back to English, the site works properly. Also Asian language functionality. Content contributions can be in original English or original Asian, content translations will work properly, all language meta tags remain correct. I see no disadvantage now for either language or its users on having English as default. So, let's continue.