You have set up a website where multilanguage content submission and display was a requirement? What was the workflow specified by the customer? How were relations between different languages defined? Did you have all content translated? Was translation into specific languages a requirement for publication? Did you translate all navigation and even site level images? What was special about that project?
An internationalization use case consists of the requirements you faced, the user workflow you needed to support, and the interface you provided to the user. We are not interested in dirty implementation details (modules, PHP code, CSS) at this stage, only higher level information about how you built up multilingual content, interface, navigation and site design. You don't even need to talk about Drupal projects. If you have any other use cases to share, which you experienced out of Drupal, we are interested. The goal of the above questions are only to start you up, don't let them stop you from sharing your story in greater detail.
You can either post a new story to this group or comment on this story with your use case. Thanks for sharing!
Comments
We were developing Drupal
We were developing Drupal business site of a Czech Republic based company. The requirements were:
www.example.com/en
www.example.com/cs
If you select "en" as default language, then www.example.com will have same content as www.example.com/en - which is duplicate for search engines.
Good behaviour should be www.example.com -> redirect to www.example.com/default-language.
i second to this... i work
i second to this...
i work with site http://cjnepal.org
we have hired a translator, and will release the nepali language files on drupal.org once complete
International site for a non-profit organization
Hi Gábor,
hi everyone,
It's great to learn that Drupal is getting more i18n-friendly.
I have just relaunched a multilingual web site for a non-profit organization which I support.
These were the requirements:
It is my first site using Drupal and I am really enthusiast with it (www.animauniversale.it).
There is still work in progress - more features to come - and the English section is pre-Drupal until I complete the translation on my test site.
I am really hoping that i18n finds its way into core soon. IMHO this would allow Drupal to achieve even greater success.
All the best and a big thank you to the Drupal community,
Riccardo
Mixed content
One use case is mixed up content. Here is a case for a Dutch writer:
A battered up, almost working example is up at threesanna.com
Bèr
http://www.webschuur.com | http://bler.webschuur.com
E-Commerce site
Running a „worldwide” e-commerce site is a hard work.
These are i18n problem too! i18n is not only a translation and language specific problem, but multi-cultural, multi-locational multi everything too!
Aries
Aries
Corporate website
Our company needs a localized website to be able to present itself both to Danish and foreign (i.e. English-speaking customers).
The requirements are simple. It must be possible to display all types of contents, including navigational stuff such as menus and URLs, in both Danish and English. Default language should be detected automatically, and two small flags shown in the header or footer should change the language. The website is mostly static contents of the brochure type where we ourselves add the contents, so the interface is not a big issue. Some content will only be available in Danish, some content will only be available in English.
Maybe this is not a terribly interesting case, but I think it covers a lot of ground, and currently Drupal doesn't get it quite right. We've fiddled quite a lot with the i18n module, and while it is flexible with regards to contents in static pages, the menu support is inadequate. You have to use a separate block instead of the primary links menu if you want pretty localized URLs.
Big corporate sites need regional sections
If we want to embrace big corporate sites, we need to support multi-lingual websites. Websites like those from Nikon and Canon, to name just two random examples, offer information about products in different languages. Sometimes it goes far beyond regular content translation though: products can have different version numbers or names in different languages (menu items, path aliases), different release dates, different whitepapers (file uploads), different pricing and different terms of services. One can argue that these should be seperate sites (and often times they are), however, often times, they need to be synchronized and coordinated in various ways (eg. press releases should only go live when translated into a number of languages).
I'm not saying we should go all the way but "regional sections" are often a key requirement for big coorporate sites, and regional sections often goes hand in hand with i18n. Support for regional section is a key selling point for big companies in uni-lingual countries (like North America).
With regional sections come all sorts of permission management. Typo3 has some interesting 'workspace features' (and 'directory mounts') which are sort of sweet. Kasper from Typo3 demonstrates various features of workspaces in a recent Typo3 videocast. You might want to dig that up. Also, Daisy (a Belgian open source CMS written on top of Cocoon) implements i18n using node versioning. Their versioning system support branches which, IIRC, is important for their i18n implementation. Might be worth checking out (as it might also help us get closer to staging). i18n tends to go hand in hand with workflow, staging and permission management.
Multi-lingual and multi-channel
l attended a CMS conference at which all the major commercial vendors were present. They differentiate between: multi-lingual and multi-channel (that is the terminology everyone is using). Some are only multi-lingual, some are both multi-lingual and multi-channel. What I was referring to in my comment above, was exactly that 'multi-channel'.
See also http://www.cmswiki.com/tiki-index.php?page=Multichannel.
(I'm not saying we should focus on multi-channel publishing. Just wanted to pass the information along.)
Govermental use
Talking to some people within the Belgian government, they need at least this:
Open standards
Looks like there are at least two standards (taken from http://www.w3.org/2002/02/01-i18n-workshop/Savourel.html):
Here are some tools and links you should check:
http://meta.wikimedia.org/wiki/How_Open/Free_content_and_Open/Free_softw...
http://www.evolt.org/PHP-Localization-with-TMX-standard
http://en.wikipedia.org/wiki/OmegaT
http://www.w3.org/2002/02/01-i18n-workshop/LocFormats
I think (not sure) that the Belgian/European government uses "Lucene".
Open Language Tools
These tools might be of interest as well: https://open-language-tools.dev.java.net/
Open Language Tools comprises a full-featured XLIFF Translation Editor and a set of XLIFF file-filters for a number of documentation and software file formats (like PO, HTML, Docbook SGML, etc.).
Only some nodes translated
In our case we only have a very limited number of nodes translated into multiple languages. We don't have any interface translations. Visitors just browse around the english website, but when a translation is available, they can switch to it using some clear links at the top of the page. (e.g. http://www.imo.net/calendar/2006 )
I have been using the "translation" module before (from 4.5), which served this purpose fine. I'm trying to archieve the same thing now with the i18n module, but I'm not really there yet.
I don't entirely agree with meba on the redirect. I do agree on the fact we need a unique path, but in my case, I'd rather have all english language content in my website available as www.example.com/some/thing instead of www.example.com/en/some/thing, and only the non-english content as www.example.com/ru/some/thing.
A non-Drupal site I
A non-Drupal site I developed was a big help desk site. The requirement was that all materials, images, help text, everything must be available in 8 languages (i.e. each language would be an exact mirror of the others). Everyone was forced to a splash page first to select a language before getting to anything else. Each page had a drop-down selector at the top of the page to allow you to switch the page to another language, and that choice was carried forward until you made another selection. Everything was developed first in English. To keep the site from breaking as it was being built, each page load first checked if the text and images were available in the requested language, otherwise English was used. It took a while to get all the text and images translated, especially the images. There were lots of screen shots to illustrate the help and that took the longest time (they needed to be created on computers that had the language installed so that all parts of the screen shot had the right text), so defaulting to English screenshots in the meantime was critical to making the system usuable.
Keep in mind your less ambitious users....
There has been feedback regarding large international websites, but please do not forget your less ambitious users. I myself have a very simple blog with some photo galleries and static pages, and I need to have that available in 3 languages (portuguese, english and german). My first attempt was with typo3, but that was a little too much to handle for a first attempt at CMS, and I could never get the blogging functionality I wanted - however, the translation system was great and easy to implement.
With Drupal, getting everything working was much easier, but content translation was harder than it should be, especially when things like translating primary links are involved. So more flexibility with url creation might be a nice idea for the noobs among you, such as me. I am enjoying drupal very much, and in fact I have have a website which is much nicer than I ever thought I would be capable of having. But internationalization in the website could be better - again, url flexibility and easily translatable menu entries would help very much.
On another note - typo3's tree view of your website makes this kind of thing much easier, because you can easily understand the structure of your site. Perhaps something like that would be desirable for drupal, and might help with i18n stuff because you would be able to quickly see the tree for different languages, for instance.
Just some ideas from a noob - if possible, keep it simple :)
greener grass
It would be nice from you, if you could write up some about your experience with typo3 and i18n in the greener grass topic. Thanks!
Government of Canada and blog perspectives
From the Government of Canada : "The Canada Site respects the Official Languages Act and is committed to ensuring all information and services on this site is available in both English and French."
User friendly and user easy
Ensuring that the website is easy to change from one language to another is a must.
For example : http://www.faa-lfi.gc.ca/fs-fi/03/01fs-fi_f.asp
This French page has the equivalent in English. Just clic "English" and you have the same page in English.
Url friendly (with mod_rewrite?)
In the example above, the only difference is the last "f" for French change to "e" for English.
It should be the administrator who would decide where the url change occur. Just like current blog, article, etc.
Before the domain? fr.drupal.org/article/18
After the root? drupal.org/fr/article/18
Inside the path? drupal.org/article/fr/18
At the end? drupal.org/article/18/fr
Url translated (with mod_rewrite!)
Since the mod_rewrite is been used for been nice with google and all the search engine, the URL should be translated if needed to.
en.drupal.org/drupal_is_thinking_about_i18n_for_the_next_version
fr.drupal.org/i18n_sera_peut_etre_dans_la_prochaine_version_de_drupal
No translation for this one
It should be noted clearly that when someone is reading a node and that there is no translations in other languages. It could be flags or red X marks...
Français?[non] Espagnol?[no] English?[no] Dutch?[da]
(I can't remember is it is "da", "ya" or "si" in Dutch for "yes", sorry for that)
Filters or no filters - there is the question
It is always a nice to be able to display all articles in one language only. Or... to post all articles, first in the current language, then in another if the first one is not translated. The current i18n does that kind of thing pretty well actually.
Selections are... Content selection mode :
-Only current language and no language
-Only current and default languages and no language
-Only default language and no language
-Only current language
-All content. No language conditions apply
Conclusion
I think that is a nice resume of what functionnality I would like to have in that kind of system. I wont repeat what is up here, so this is it.
...
How about character set support for URL's? If I'm not mistaken you can't use e.g. a japanese character set for URL's... Even some accents in French for example might give trouble. Just to say we might have to be very carefull about this.
Probably depends on the situation, but I'd say if someone is reading a node in a certain language, it's by far more interesting to know which other languages are available. If a translation isn't there, I can't see much reason to attract the attention to that... But again, it probably depends on the situation...
It's "ja" :-)
Japanese chars in "URL"s
Internationalized Resource Identifiers (IRIs), the successor of URIs, which are the successor of URLs are supposed to solve this problem. At least after browsers will suport them properly.
standards
Well, that is the job of the "path module". He should be the one to change letters that does not have conformity to the current web standards. For example, spaces are now converted in "_".
Redaxo: CMS with core multilinguism
Redaxo is a simple, flexible CMS with buildin content translation. You have nested content categories with articles. The content translation is done article wise. Articles consist of "article slices". The page redering code can use the object oriented Redaxo api which provides information about the translation state of an article.
Project home page (in German language):
http://www.redaxo.de/
Take a look at the references. Some of them have multilingual content:
http://www.redaxo.de/149-0-referenzen.html
Alessandro
Multilanguage and multidirection
Our site is bi-lingual (Hebrew/English). We found the i18n matched our needs, as our requirement were:
This does create a few idiosyncrasies, such as my blog having two feed (one in Hebrew and one in English). It is fine for us, but might be a problem for others. The languages switches now has as many options as there are languages. An N+1 options (show all content, maybe with a UN flag...) could be handy.
Language direction
I do however, see a case for seeing content from all languages (e.g. blogs). This brings out the issue of language direction. Arabic, Farsi, Hebrew and Yiddish (to name a few). I am note sure where LTR-RTL handling should be done, one the page or on the node, but it seems that it might be needed on both.
At the moment, if we show content from both languages, the direction is set by the main interface language.
Internationalization and localization
Here is a tricky one. Does language infer locality? I can see a case for translation being locally dependent (think of and English/French site catering for France, Canada, the UK and the US). Specifics of a translation (say a local sales office) would be different, but would it require a complete instance of the translation?
Language naming might be an issue. Is language synonym with a locality? This works for us (HE for Hebrew is the same in peoples mind as IL for Israel), but will not necessarily work for Arabic.
URL Management
While we find www.sysnet.co.il/he and www.sysnet.co.il/en acceptable, others might not. The language might be a suffix (ex. node/en) or a host prefix. I could think of not having it in the URI at all (using a cookie, perhaps). The best would be site setting.
Gil Freund
SysNet
Efficient internationalization
I have a small private site http://www.manveru.pl with polish content. I've installed i18n module and tried to translate some nodes. Node translation itself is easy to use. But that's all. If I want use panel module (not in core) I experienced much problems:
- If I tie node with one of frames in panel, it is alway the same independently on language set (I know it may be panels module issue, but if i18n will be integrated into core, they may update this).
- Views does not support internationalization at all - I think that they should support a current language filter (or other filters). In case of selecting taxonomy term I can select all language version, but if view module can tie translated taxonomy terms, it may be very helpful.
- Ability to translate menus are available by multi-language blocks, which is completly unuseful - menu items should support multilanguage names and maybe even multilanguage urls.
- The page title, subtitle and motto are always in the one language. That is a problem. They can be translated by locale module, but now it does not work.
You should look at the localizer module which add some additional functionalities to i18n.
I hope you handle all the internationalization issues soon and with very good results.
I appreciate hearing other's
I appreciate hearing other's experiences with using drupal in a i18n environment. I am currently in the process of transfering over from an old system our large multi-lingual site. (Currently 18 languages and growing). We originally set out to write a system ourselves but only ended up getting the public end done 3 years ago and have stagnated since then. We are now moving to drupal so that we don't have to start from scratch.
URL Structures
We have moved from a structure of having prefixes to the URL's (ie: de.drupal.org, fr.drupal.org) I would like to see the option of keeping that kind of structure, using suffixes as currently is supported, or alternately even supporting seperate domains (ie: drupal.de, drupal.fr, etc)
Translation Permissions and Unified Interface
While something like this may exist that I don't know about yet, I would like to have the ablity to assign a user or a roll the permision to translate for a specific language. (ie: "Translation - FR" has permission to translate things into French)
Additionally, the abiltiy to have one unified interface for seaching and translating all untranslated content for a language. The translator could sign in and see that they have nn number of untranslated articles/nodes.
Content Not Localized
In our prior system we had the concept of showing all content, but if there was a section, or topic, that was not translated, we put up a message that said in effect: "This section is not available in your language. We will display it in English for you if you like." As well as a check box to not display these messages again.
I appreciate seeing this discussion happening and I look forward to being able to participate more in the drupal community.
Plone was the end choice
We are an NGO based in Sweden currently developing our new site. It's running as a testsite on the test site url http://www.twigashop.se (under active and heavy development right now).
The English side of the site is woefully underdeveloped at the moment - the site is in active development! Please do not take this as a failure of Plone etc - we have been working on other issues and we are a very small team who have a lot to do:)
Our site is being developed in Swedish and English. This is very important. Our main organisation membership is in Sweden but most of our projects are in Africa, namely Uganda and Kenya where English is widely spoken.
We choose Plone - after much looking around for a solution that just 'worked' we selected Plone with the LinguaPlone product and the Plone Language Tool.
We really liked the split pane view for translations - you get the source language appearing on the left with the editing pane for the translated text on the right site of the screen.
We really like that you can click one flag icon and the whole site switches languge and remembers your choice.
We have a fully functioning offline version of our site and everything works beautifully. The online test site has only recently been put up and is more a testbed for our efforts to learn Plone 2.5 (we originally developed on 2.1.3). The actual site it is to replace is twiga.se
The site is in no way finished or even half complete, in fact most of the language tools are not installed yet - however we have done a hell of lot of testing offline and we know it's robust and just works.
I apologise as my English is not so good!
radicalparty.org
www.radicalparty.org
we are needed an internazionalization system. Now our site is a little bit old and we are trying to migrate on Drupal.
At this link you can see this try.
http://servizi.radicalparty.org/drupal/
for this site we use Drupal and I18 module.
We have migrated more than 20.000 old documents in this new site.
Our needs.
Is a system that could publish various language home pages.
A sytem that for some languages (let’s say chinese) publish also the english text of the news
A way that admin can determinate the language importance and view (becouse we will never have all the content in all languages)
Es. For chinese
First lang: CH
Second lang: EN
Third lang: FR
Ecc
For ITALIAN
First lang : IT
Second lang: SP
Third lang: EN
Ecc, ecc
A system that could publish one news in english (let’s say) on the italian home page also (admin choose)
We need (there is an emrio of that) a sytem that can let people translate the content o ouar site, with various levels of admin power.
Anon can transalte but the translation must be rewieved by an transaltor,
Translator can translate and publish without review
Transaltor can modify the transnation of another translator.
Admin can make all
Also this system must have an email remainder. Let’s say that the admin publish a new news in italian. An email goes to the “translators”, for that language. First arrived start to make the translation, and for that time the others can’t start or modify this node.
Also, how you see we need navigation based on tags
http://servizi.radicalparty.org/drupal/it/taxonomy/term/105
this is a little list of our needs. Becosue there are more others :) like petition system in various languages. Comments system, ecc, ecc
If you are interested please dorp me a line and I will make the long list.
Thanks,
Mihai Romanciuc
Webmaster of radicalparty.org
Multilingual users
Hello, first of all, I would like to thank both Jose A. Reyero (author of the Internationalization module) and Roberto Gerola (author of the Localizer module) for their great efforts in the localization issue. While I think that the second is much more better in terms of functionality, it evolved from the first and therefore show many similarities. Also it seems like most people are still installing the first (I wonder why?).
I want to add a new use case to the ones that have been said before:
A user needs one only locale for the user interface. When the user is anonymous, it can be automaticaly selected either from his/her browser detection or from his/her IP origin (by using the IP_to_country facilities provided by some contributed modules). Once the user is registered, it is probably better to consider the locale which he/she chose during the registration process.
But, that is what is new, the user wants to access the site content written in any of the languages that he/she can understand. Maybe I chose English for the user interface, but as far as I can understand Spanish as well, I would enjoy to read any post written in English or Spanish.
In my opinion, the user profile should be extended to include the multilingual concept. That way, it would be a list of locales rather than an only locale.
Regards to the Drupal community!
Multilingual users
Thank you for your feedback.
--
http://www.speedtech.it
--
http://www.speedtech.it