Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By webclaus on
Guys,
Have anyone considered an approach to reflect the current locale in the URLs? My non-drupal site, techwriter.dk is available in English and Danish, and in order for crawlers to pick up both languages, I embed the language indication in every URL, prefixing everything with either "en" or "da" (techwriter.dk/da/about.html and techwriter.dk/en/about.html) and equip each page with a "swap language" link.
Now, is there any way of doing this in Drupal, or is locale settings purely session based.
Comments
sounds like trouble... *but*
Because of drupal's url schemes (and their direct use by modules), I think you may find there's way too much module patching required to get this to work the way you want. And given the relatively low number of multi-lingual sites drupal currently serves, you may find it hard to get this committed. however, a 'swap language' link is much less onerous. check out <self-promotion>Terminus1525 or this site for WSIS</self-promotion> for examples. both cases required a simple patch to locale_init() (in common.inc) to set the current language via a $_GET parameter (in addition to session / user prefs). I'm also interested in getting that functionality into core.
You may also be interested in my translate_node.module (in the contributions CVS repository)
--
James Walker :: http://walkah.net/
Multilingual sites
One of the reasons for the relatively low number of multi-lingual sites is probably that things like this isn't working. The locale module isn't very userfriendly doesn't help either. Basically if you are considering multilingual sites another framework is probably more suited.
Types of multilingual sites
It is true that, at least for a Drupal newcomer, setting up a multilingual site is not easy. The locale module is not that clear and friendly, I've read the information related a couple of times and still I don't quite get what it does and what it doesn't (although I agree I should possibly read it for a third time). :)
When I started playing with this locale module I selected Spanish language and the first thing I got was a weird symbol in any "ñ". I also wanted to add Catalan but it doesn't appear in the list so I guess it will be more complicated to have it (although there is a Catalan Drupal site). Since I'm setting up the brand new Drupal site and the to-do list is still big, I decided to leave the locale thing for later, and in the meantime read posts like yours to see if something clearer comes out.
(I'm not writing this with autobiographical purposes, it's just to show that The Multilingual Issue is faced generally by administrators that are in their first steps in Drupal - and oftem have a basic knowledge of English, but this is another problem)
In order to help developers to sort this out maybe it would be useful to make clear that there are different types of multilingual sites, and see what is the best solution for each case:
1. Simple: different locale interfaces, same organization of data
For instance in Catalunya or Quebec most people is bilingual so they can understand almost equally Catalan/Spanish or French/English. You want to let users select they preferred interface but the content submitted is equally accessed by all of them. In other words, the content of your homepage is mixed and you see the same no matter what locale you select for your interface. There are only some static pages about the site that are offered in both languages and you would like to have the appropriate links in each interface (i.e. the "About us" page in French when the interface is in French and in English when the interface is in English). There may be other implications related to calls to some links and images (i.e. the header of the site with the motto in locale).
2. Localized: different locale interfaces, different organization of data
The same as above but you want that users with Catalan interface see primarly the contents in Catalan. This possibly can be solved by solving the 1.Simple issues and working with the taxonomy, adding a language vocabulary to select in which laguage(s) is written the content submitted. Note that in this case there is no need to translate content submitted, if you go to the French homepage you'll have simply different contents that if you go to the English homepage.
3. Translated: different locale interfaces, same organization of data but all (or most of) the content is translated
For this you need to have solved the Simple and Localized issues... You could create new nodes with the translations but this wouldn't be the best solution. It would be good to offer at least automatic links to the available translations of any page (for that the system must know that article A and B are twins). And a translations manager (to know which articles have been translated, which are being translated now and so on) would be quikly needed as far as your site grows and you have, for instance, a group of voluntary translators.
It is possible that for the most of people wanting to have a multilingual Drupal site 1.Simple would be enough (this is for instance my case). Some others would be happy with 2.Localized and just very few want to head to a 100% 3.Translated site, due to the amount of work it takes.
I'm not saying that we shouldn't offer 3.Translated but it can't be possibly done before having before good solutions for 1.Simple and 2.Localized.
We are at 'Step One'
The current CVS development version of Drupal (without additional modules from contrib) is at step one (from the above explanation). We are still working on making the interface translation better and would not like to go too far too soon without a clear strategy. Since currently it is even not possible to translate the site slogan (motto) into different languages, we need to solve this level of problems first. Node translations and content language (auto)selection will come later.
In the last few months we have put a lot of effort to bring the gettext style of interface translation to Drupal, which will make interface translation a lot easier then ever before. Since translated content is not worth a cent without translated interface, I think that we are on a good way.
content vs interface localization
I have to jump in and say that the last point, about the relative value of localized interface vs content is a bit off the mark, IMHO.
In many countries in which Internet usage has become widespread, there is some familiarity with English words at least as they are commonly used on the web-- words like "home", "index", "forum", "download" and so forth. In fact, many technology-specific words have been "imported" from English into other languages where previously no appropriate word existed.
I'd say that most users are capable of dealing with a foreign language interface. What they can't deal with-- without something like Babelfish or Lingvo-- is long-form content in a foreign language. I run three Drupal sites that have some measure of foreign-language content, and the stumbling block for all three was having a sensible way to navigate between content in different languages: being able to set a preferred language, having an interface for translating content, performing "fallback" to the default language when no localized version was available, etc. It's much more critical than the interface itself, most of which can (and routinely is) done by hand through the localization module.
If there are places where the Drupal interface runs into problems with localization, it's not so much about what language it's in, but questions about whether or not terms like "collaborative book" mean anything to anyone, English-speaking or not. :-)
Editor interface and user interface
I think that the comment by dmjossel needs adding to. In my case, I am concerned with editors and visitors. For editors, an English language interface is acceptable (though nice to have other translations). For visitors on the other hand, the interface language should be the same as the content that they are displaying.
common.inc changes.
walkah,
Could you briefly outline the changes (in a way that a PHP novice could grasp!) that are needed to locale_init() to get the language-swap functionality as shown on your pages.
Thanks.
Mass URL aliasing
You need to know a lot about Drupal URL schemes, the inner data handling of Drupal and regular expressions, but current CVS version of Drupal provides you with the ability to add mass URL aliases by hooking into the URL aliasing process. See the help in path.module (CVS version!).
With that you can intercept the incoming URL handled by Drupal and remove the language prefix, and set it in a session or a global variable. You can also add a language prefix to URLs as needed (you need to code this in PHP). The swap link is easy to accomplish in your theme, in case you have everything in both languages.
Sounds promising
This could very well be what I was looking for - I'll take a closer look. Thanks.