I18n questions and troubles
Hello, I have some basic questions about i18n module, hard to explain, so there is a basic use case : I have two languages, french (fr) and spanish (es); I have to translate every node to both language (so I use the "translations" tab to create and link nodes from both languages),; I have only one big menu, which is translation enabled (so one entry for both language, but translated); Let's say I have a french node: "node/XX"; and its translation in spanish: "node/YY". The question is, when I go to path "fr/node/XX", my french node is displayed, but when I switch to spanish, cliking the spanish language switch link, my new path is "es/node/XX", does the i18n module automatically switch the displayed node to "node/YY", or does I always have to manually switch the path to "es/node/YY" ? The problem behind this is my menu is the same in french and spanish, so when I click on a spanish entry from the menu, the path will be the french node's path, but prefixed with "es/", but my french node is always displayed, which is not what I want... Thanks in advance for help.
On Mon, 28 Apr 2008 10:16:59 +0200 "Pierre <pounard> Rineau" <pounard@processus.org> wrote:
Hello,
I have some basic questions about i18n module, hard to explain, so there is a basic use case :
I have two languages, french (fr) and spanish (es); I have to translate every node to both language (so I use the "translations" tab to create and link nodes from both languages),;
I have only one big menu, which is translation enabled (so one entry for both language, but translated);
Let's say I have a french node: "node/XX"; and its translation in spanish: "node/YY".
The question is, when I go to path "fr/node/XX", my french node is displayed, but when I switch to spanish, cliking the spanish language switch link, my new path is "es/node/XX", does the i18n module automatically switch the displayed node to "node/YY", or does I always have to manually switch the path to "es/node/YY" ?
The problem behind this is my menu is the same in french and spanish, so when I click on a spanish entry from the menu, the path will be the french node's path, but prefixed with "es/", but my french node is always displayed, which is not what I want...
What I did to recycle menu was to use an agnostic menu and locale that just translate the text. i18n take care of the language prefix in the path. The only draw back is the overall path is not translated. So you've a menu entry that is eg. d1/documents (path in the menu entry) and Documents as text i18n will prefix the path with the language localisation will translate Documents into eg. Documentos[1] Then you write the es and fr version behind d1/documents with es/documents and fr/documents path. When you're in es mode the menu will take you to es/documents and the menu text (provided you translated it with localisation) will show Documentos. When you're in fr mode the menu will take you to fr/documents and the menu text will show Documents[2]. What I haven't been able to achieve is having the path translated too... so that Documentos will take you to es/documentos and Documents will take you to fr/documents. I think it is achievable but I never dig into it enough. In my use case users tend to switch between language if they are not finding what they are looking for, since not all translation have all the pages. So I provide different taxonomies for different languages that are always visible and I use the above trick just for primary links so I do have taxonomies translated... even if users can't switch between taxonomies of different levels... but they can try to switch between articles, and articles provide a bridge between taxonomies. It would be nice to have a bridge between taxonomies with a fall back system that takes you to the nearest point between languages, since in my use case not all languages follow the same dev path it may happen that some leaves of a taxonomy in one language are missing. It depends on your use case... if you feel that path are important you may put more effort into actually translating and mapping everything. [1] I just saw an Italian advertising that says that it is not enough to add an s to every Italian word to make it Spanish, but I think at least this one is correct [2] this time I had to check with Google. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On lun, 2008-04-28 at 11:23 +0200, Ivan Sergio Borgonovo wrote:
On Mon, 28 Apr 2008 10:16:59 +0200 "Pierre <pounard> Rineau" <pounard@processus.org> wrote:
Hello,
I have some basic questions about i18n module, hard to explain, so there is a basic use case :
I have two languages, french (fr) and spanish (es); I have to translate every node to both language (so I use the "translations" tab to create and link nodes from both languages),;
I have only one big menu, which is translation enabled (so one entry for both language, but translated);
Let's say I have a french node: "node/XX"; and its translation in spanish: "node/YY".
The question is, when I go to path "fr/node/XX", my french node is displayed, but when I switch to spanish, cliking the spanish language switch link, my new path is "es/node/XX", does the i18n module automatically switch the displayed node to "node/YY", or does I always have to manually switch the path to "es/node/YY" ?
The problem behind this is my menu is the same in french and spanish, so when I click on a spanish entry from the menu, the path will be the french node's path, but prefixed with "es/", but my french node is always displayed, which is not what I want...
What I did to recycle menu was to use an agnostic menu and locale that just translate the text. i18n take care of the language prefix in the path. The only draw back is the overall path is not translated.
So you've a menu entry that is eg. d1/documents (path in the menu entry) and Documents as text i18n will prefix the path with the language localisation will translate Documents into eg. Documentos[1]
Then you write the es and fr version behind d1/documents with es/documents and fr/documents path.
When you're in es mode the menu will take you to es/documents and the menu text (provided you translated it with localisation) will show Documentos. When you're in fr mode the menu will take you to fr/documents and the menu text will show Documents[2].
What I haven't been able to achieve is having the path translated too... so that Documentos will take you to es/documentos and Documents will take you to fr/documents. I think it is achievable but I never dig into it enough. In my use case users tend to switch between language if they are not finding what they are looking for, since not all translation have all the pages. So I provide different taxonomies for different languages that are always visible and I use the above trick just for primary links so I do have taxonomies translated... even if users can't switch between taxonomies of different levels... but they can try to switch between articles, and articles provide a bridge between taxonomies. It would be nice to have a bridge between taxonomies with a fall back system that takes you to the nearest point between languages, since in my use case not all languages follow the same dev path it may happen that some leaves of a taxonomy in one language are missing.
It depends on your use case... if you feel that path are important you may put more effort into actually translating and mapping everything.
[1] I just saw an Italian advertising that says that it is not enough to add an s to every Italian word to make it Spanish, but I think at least this one is correct [2] this time I had to check with Google.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
What I figured out until now is there is two clean ways of handling a multilingual site: 1) Use two menus, one fr, the second es, and try to synchronize them manually every time you have to add an entry. With this option, no worries about the pathes, because you have one entry per language, so you can specify the path you want for each language. 2) Use one menu, translated, and set to aliases for each translated page, the fr node is fr/myalias, and the es is es/myalias. The problem with this one is YOU HAVE to set a path for each node you want to be translated, and then you can't translate these pathes. I'm currently orienting my choice to the second option, because maintening two menus, when there are someting link about 100 entries is to much work, but this is fastidious to set a path to every page.. The problem beside this, is there is no real synchronisation between translated nodes, all informations are duplicated (owner, rigths, taxonomy, etc), this is BAD because synchronisation is hard to maintain in time, and if I go to node/120 (fr), but browsing in spanish, this will be more convenient for users to land on the spanish translation without having to worry about pathes and menus. I will be glad to ear every other simple solution you have :)
On Mon, 28 Apr 2008 11:35:11 +0200 "Pierre <pounard> Rineau" <pounard@processus.org> wrote:
I will be glad to ear every other simple solution you have :)
I think that translation require a cost and responsibility. Nodes provide a bridge between translations. You have tools to have similar bridges for menus. Generally I think that planning menus/taxonomies requires more editorial consciousness compared to writing or translating articles. So generally this cost fall down on me ;) Writing an article and writing a translation is not that different than writing a menu and it's corresponding translation. In my use case menus path are generally in the range of 100 and articles in the range of thousands. All this stuff about clean urls is done for SEO and helping people remember urls I think. Once you've thousands articles, the weight of few menu path for SEO may be negligible. I do wonder if really people will remember urls once they start to be too much complex... if you've 100 menu entries that point to clearly identifiable categories it may be worth to translate them. If they start to be too complex in terms of concept and length translating the path may not be worth the effort. I think it is just a matter of evaluating the ROI and how and if you're willing to delegate to editors menu editing and taxonomies too. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting "Pierre <pounard> Rineau" <pounard@processus.org>:
I will be glad to ear every other simple solution you have :)
Sounds like some modifications to pathauto might help with the path translations. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Thank you all, After all, I choosed the two-menu solution. I will maintain two menus in parallel, one for each configured language, solution that Ivan Sergio Borgonovo seems to recommand. He's right, the fact is there is many less menu entries than there is articles, so it's simplier to maintain. Have a good day!
On Mon, 28 Apr 2008 13:38:46 +0100 "Pierre <pounard> Rineau" <pounard@processus.org> wrote:
Thank you all,
After all, I choosed the two-menu solution. I will maintain two menus in parallel, one for each configured language, solution that Ivan Sergio Borgonovo seems to recommand.
I didn't recommend that route. I just pointed out it is one of the available and you've to take into account delegating responsibility to edit menu and the return of having path translated. I actually did follow the other route. It would be nice to have some stats on how much paths have an impact on SEO and how many people use urls to remember sections of a website. I use direct urls typing to stroll around sites I'm developing but I'd say that if people have to remember url to navigate a website, navigation should be improved. So I'd be more concerned about SEO... but if you've a hierarchy of 100 items in a menu and thousands articles... I wouldn't think those hundred links will have a relevant impact over SEO. Just hot air unsupported by any stats anyway, it would be nice to have some supported opinion. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (3)
-
Earnie Boyd -
Ivan Sergio Borgonovo -
Pierre <pounard> Rineau