Hello,
I am currently setting up a multi-country / multi-language site, using one database and one code base. The reason for this is that 90 percent of the content will be shared. I will use 5 different domains for all the countries, using the domain access module package. All domains should have a different default language.
As I am still a the early phase of development I want to prevent issues later on. I am aware of possible broken translations when changing default language. I have done a lot of research on the fora, but I am still confused and I need your help in summarizing the current issues, so that I can make the right choices. The same holds for Taxonomy translations.
A few questions to situate the problem:
-can anybody reference to a clear explanation on the crucial difference between t(), tt() and locale() ? Which is best used in code of a setup like mine?
-what is best use of taxonomy: 'localize terms' or 'per language terms' ?
-what is the best way to attaching different default languages for each domain, no causing translation issues on other domains?
-is there a way to use browser cookies to remember the preferred language of a user ?
Any experience, suggestions, references and best practices are really appreciated.
I love drupal, and I really want to learn to make best use of it. Internationalization has always been one of the parts I understood less... Thanks for your help !
Maarten.
Comments
I've already built a site
I've already built a site pretty similar to yours so here's my 2 cents:
1. Use domain_locale to get different default languages/language sets per domain
2. in a custom module always force users to use the default domain to translate strings (Domain Access has a hook to forces user to use the form on the default domain)
3. I have gone mostly with t(). tt() comes in handy when translating taxonomy terms if you are using i18ntaxonomy. locale() is called from t() so there's no reason to bypass it and lose all the performance stuff it provides you with.
4. I have chosen 'localize terms' solution for some vocabularies (eg. I need the term ID always to be the same number) while for others "per language terms" is a better solution (think Glossary module for example)
5. You can get the current language from global $language object if needed.
http://africa.thebeehive.org is a site that is not quite ready content wise but demonstrates the functionality you are after. The default domain lists 4 languages with English being the default language while http://kenya.thebeehive.org only has two and the default language is Swahili.
domain_locale and cookies
Hello nonsie,
Thanks for your 2cents. I have had a look at your sites and it is interesting to see that you have a similar setup indeed.
I had tried the domain_locale module just today, but it gave me some warnings and errors. I saw that you are the developer or maintainer of this module and that it is still in beta. How is development going? I think this is not the right place to write about these issues, just wanted to tell you this.
Do you have experience with using cookies to set the language of a visitor? In Belgium we have 3 official languages, so we cannot use the domain to determine the default language here. I was thinking to exceptionally add a custom cookie check in languages.inc > language_initialize().
And another question, am I right that when using taxonomy with localize terms, the source language is always considered to be English if no vocabulary language is given.
Related to string translation, I have been testing different settings, and I noticed that the problem lies in the default string translation section of core. However when using the l10client I can translate de source strings to any language enabled... as if the i10client does not link the source strings to the default language and the string translation does... Am I right or do I forget something ? And the i10client does not seem to catch taxonomy term translations well...
Thanks for you help,
Maarten
I consider Domain Locale
I consider Domain Locale fairly stable but if you did encounter any errors, please report them in the issue queue. It has a very specific use case and so far I only know a handful of people using it.
If you do decide to go with Domain Locale one thing to keep in mind is that it requires settings language negotiation to "Path prefix only". This means you'd need to write a custom module to redirect user to the correct language node based on cookie setting/HTTP header.
Source language is always the default language of the site (think Drupal install without Domain Access)
Perhaps this thread will explain it a bit better - http://groups.drupal.org/node/24438#comment-86555
help needed
Hi nonsie
u commented above
"This means you'd need to write a custom module to redirect user to the correct language node based on cookie setting/HTTP header."
Can you please elaborate on the same. I am trying out a multidomain install with different default languages, but it is not picking up the default language for menus etc on the different language, so needed some pointers.
Thx
Suchi
In includes/common.inc, there
In includes/common.inc, there is some good info of how to use t()
"t() is designed for handling code-based strings, in almost all cases, the actual string and not a variable must be passed through t().
Extraction of translations is done based on the strings contained in t() calls. If a variable is passed through t(), the content of the variable cannot be extracted from the file for translation.
The only case in which variables can be passed safely through t() is when code-based versions of the same strings will be passed through t() (or otherwise extracted) elsewhere.
However tempting it is, custom data from user input or other non-code sources should not be passed through t(). Doing so leads to the following problems and errors:
- The t() system doesn't support updates to existing strings. When user data is updated, the next time it's passed through t() a new record is created instead of an update. The database bloats over time and any existing translations are orphaned with each update.
- The t() system assumes any data it receives is in English. User data may be in another language, producing translation errors.
- The "Built-in interface" text group in the locale system is used to produce translations for storage in .po files. When non-code strings are passed through t(), they are added to this text group, which is rendered inaccurate since it is a mix of actual interface strings and various user input strings of uncertain origin."
tt() is for variables, things that either users or administrators can edit in the gui.