Re: i18n usage
Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: added project.configfile=/var/tmp/fs/cli.xconf to forrest.properties modify cli.xconf and add this line: I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: localhost:/index.html?locale=es or localhost:/index.html?locale=fr cheers, helena David Crossley wrote: Ross Gardler wrote: Helena Edelson wrote: i am also working on i18n. when i figure it out, i was thinking it might be help ful to write a how to. everything so far seems fractured in terms of the steps to take to implement. there are many if then's and info is everywhere, from docs to jira to cocoon docs.. te a start is what is needed. Yes, use one catalogue file per language. Yes we do need to bring it all together in the forrest docs. -David
Re: i18n usage
Hi, It doesn't make sense to have to add this: modify cli.xconf and add this line: if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1" exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: added project.configfile=/var/tmp/fs/cli.xconf to forrest.properties modify cli.xconf and add this line: I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: localhost:/index.html?locale=es or localhost:/index.html?locale=fr cheers, helena David Crossley wrote: Ross Gardler wrote: Helena Edelson wrote: i am also working on i18n. when i figure it out, i was thinking it might be help ful to write a how to. everything so far seems fractured in terms of the steps to take to implement. there are many if then's and info is everywhere, from docs to jira to cocoon docs.. te a start is what is needed. Yes, use one catalogue file per language. Yes we do need to bring it all together in the forrest docs. -David
Re: i18n usage
Finally, Does anything in this cocoon info page need to be implemented? http://cocoon.apache.org/2.1/userdocs/i18nTransformer.html thank you, helena Helena Edelson wrote: Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: added project.configfile=/var/tmp/fs/cli.xconf to forrest.properties modify cli.xconf and add this line: I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: localhost:/index.html?locale=es or localhost:/index.html?locale=fr cheers, helena David Crossley wrote: Ross Gardler wrote: Helena Edelson wrote: i am also working on i18n. when i figure it out, i was thinking it might be help ful to write a how to. everything so far seems fractured in terms of the steps to take to implement. there are many if then's and info is everywhere, from docs to jira to cocoon docs.. te a start is what is needed. Yes, use one catalogue file per language. Yes we do need to bring it all together in the forrest docs. -David
Re: i18n usage
Hi, first of all: Our site at http://www.verit.de is already running in i18n-mode (currently only de and en is supported) using the servlet approach and dynamic language detection using forrest 0.7. I think from your description you are almost there: - Setting project.i18n=true in forrest.properties is the right thing to do. - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this is what we did also and it worked as advertised. - Yes, to my knowledge all your pages have to be translated seperatly. Especially if you want to support 10 or more languages this will make structural changes in your pages cumbersome to maintain. We already suffer from this with just our two languages. The above scheme worked for translating almost everything but some settings defined in skinconf.xml (e.g. the feedback link). Especially we never had to touch anything on the sitemap level. HTH, Torsten Helena Edelson wrote: Hi, It doesn't make sense to have to add this: modify |cli.xconf| and add this line: dest=”/var/tmp/fs/build/i18n/*.en” /> if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1"; exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties| modify |cli.xconf| and add this line: dest=”/var/tmp/fs/build/i18n/*.en” /> I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: localhost:/index.html?locale=es or localhost:/index.html?locale=fr cheers, helena David Crossley wrote: Ross Gardler wrote: Helena Edelson wrote: i am also working on i18n. when i figure it out, i was thinking it might be help ful to write a how to. everything so far seems fractured in terms of the steps to take to implement. there are many if then's and info is everywhere, from docs to jira to cocoon docs.. te a start is what is needed. Yes, use one catalogue file per language. Yes we do need to bring it all together in the forrest docs. -David -- Torsten Stolpmann Geschäftsführender Gesellschafter EMail: [EMAIL PROTECTED] verit Informationssysteme GmbH Phone: +49-(0)631-30335580 Luxemburger Str. 5 Fax : +49-(0)631-30335581 D-67657 Kaiserslautern Web : http://www.verit.de
Re: i18n usage
With things as they are now in my test, if my browser is on language n, the document (lang n) is served but I haven't gotten it to also to tabs and menues yet I see on other forrest sites it is working so I think I'm missing one thing. In my initial test I used the file naming conv index.es.xml and changed it not thinking it made a difference but I shall change it back and see. *Do you mean you didn't have to modivy or add anything to sitemap? Thanks, Helena Torsten Stolpmann wrote: Hi, first of all: Our site at http://www.verit.de is already running in i18n-mode (currently only de and en is supported) using the servlet approach and dynamic language detection using forrest 0.7. I think from your description you are almost there: - Setting project.i18n=true in forrest.properties is the right thing to do. - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this is what we did also and it worked as advertised. - Yes, to my knowledge all your pages have to be translated seperatly. Especially if you want to support 10 or more languages this will make structural changes in your pages cumbersome to maintain. We already suffer from this with just our two languages. The above scheme worked for translating almost everything but some settings defined in skinconf.xml (e.g. the feedback link). Especially we never had to touch anything on the sitemap level. HTH, Torsten Helena Edelson wrote: Hi, It doesn't make sense to have to add this: modify |cli.xconf| and add this line: if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1" exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties| modify |cli.xconf| and add this line: I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: localhost:/index.html?locale=es or localhost:/index.html?locale=fr cheers, helena David Crossley wrote: Ross Gardler wrote: Helena Edelson wrote: i am also working on i18n. when i figure it out, i was thinking it might be help ful to write a how to. everything so far seems fractured in terms of the steps to take to implement. there are many if then's and info is everywhere, from docs to jira to cocoon docs.. te a start is what is needed. Yes, use one catalogue file per language. Yes we do ne
Re: i18n usage
Helena Edelson wrote: With things as they are now in my test, if my browser is on language n, the document (lang n) is served but I haven't gotten it to also to tabs and menues yet I see on other forrest sites it is working so I think I'm missing one thing. looking at your post again - it is 'menu_es.xml' not 'menus_es.xml' (just to make sure). I'll give an example from our sources (HTH): documentation/content/xdocs/tabs.xml: ... translations/tabs_de.xml: Produkte ... translations/tabs_en.xml: Products ... In my initial test I used the file naming conv index.es.xml and changed it not thinking it made a difference but I shall change it back and see. Please do so. *Do you mean you didn't have to modivy or add anything to sitemap? Exactly. Thanks, Helena No problem. Torsten Torsten Stolpmann wrote: Hi, first of all: Our site at http://www.verit.de is already running in i18n-mode (currently only de and en is supported) using the servlet approach and dynamic language detection using forrest 0.7. I think from your description you are almost there: - Setting project.i18n=true in forrest.properties is the right thing to do. - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this is what we did also and it worked as advertised. - Yes, to my knowledge all your pages have to be translated seperatly. Especially if you want to support 10 or more languages this will make structural changes in your pages cumbersome to maintain. We already suffer from this with just our two languages. The above scheme worked for translating almost everything but some settings defined in skinconf.xml (e.g. the feedback link). Especially we never had to touch anything on the sitemap level. HTH, Torsten Helena Edelson wrote: Hi, It doesn't make sense to have to add this: modify |cli.xconf| and add this line: follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” /> if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1"; exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties| modify |cli.xconf| and add this line: follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” /> I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: localhost:/index.html?locale=es or localhost:/index.html?locale=fr cheers, helena David Crossley wrote: Ross Gardler wrote: Helena Edelson wrote: i am also working on i18n. when i figure it out, i was thinking it might be help ful to write a how to. everything so far seems fractured in terms of the steps to take to implement. there are many if then's and info is everywhere, from docs to jira to cocoon docs.. te a start is what is needed. Yes, use one catalogue file per language. Yes we do need to bring it all together in the forrest docs. -David -- Torsten Stolpmann Geschäftsführender Gesellschafter
Re: i18n usage
I have tabs_(lang-code).xml and menu_(lang-code).xml for each language, yet still the index.(lang-code).xml is the only one returned. Could my issue lie perhaps in the translations/langcode.xml file? I added de,fr,no to what is in the distribution yet even with my browser in de, still no luck with menu, tabs or CommonMessages_de.xml for skin. I must be missing one step? helena Torsten Stolpmann wrote: Helena Edelson wrote: With things as they are now in my test, if my browser is on language n, the document (lang n) is served but I haven't gotten it to also to tabs and menues yet I see on other forrest sites it is working so I think I'm missing one thing. looking at your post again - it is 'menu_es.xml' not 'menus_es.xml' (just to make sure). I'll give an example from our sources (HTH): documentation/content/xdocs/tabs.xml: ... translations/tabs_de.xml: xml:lang="de"> Produkte ... translations/tabs_en.xml: xml:lang="en"> Products ... In my initial test I used the file naming conv index.es.xml and changed it not thinking it made a difference but I shall change it back and see. Please do so. *Do you mean you didn't have to modivy or add anything to sitemap? Exactly. Thanks, Helena No problem. Torsten Torsten Stolpmann wrote: Hi, first of all: Our site at http://www.verit.de is already running in i18n-mode (currently only de and en is supported) using the servlet approach and dynamic language detection using forrest 0.7. I think from your description you are almost there: - Setting project.i18n=true in forrest.properties is the right thing to do. - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this is what we did also and it worked as advertised. - Yes, to my knowledge all your pages have to be translated seperatly. Especially if you want to support 10 or more languages this will make structural changes in your pages cumbersome to maintain. We already suffer from this with just our two languages. The above scheme worked for translating almost everything but some settings defined in skinconf.xml (e.g. the feedback link). Especially we never had to touch anything on the sitemap level. HTH, Torsten Helena Edelson wrote: Hi, It doesn't make sense to have to add this: modify |cli.xconf| and add this line: if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1" exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties| modify |cli.xconf| and add this line: I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know
Re: i18n usage
Helena Edelson wrote: I have tabs_(lang-code).xml and menu_(lang-code).xml for each language, yet still the index.(lang-code).xml is the only one returned. Could my issue lie perhaps in the translations/langcode.xml file? I don't think so, nothing unusual over here. I added de,fr,no to what is in the distribution yet even with my browser in de, still no luck with menu, tabs or CommonMessages_de.xml for skin. The only advice I could give at the moment is to watch the error/debug logs in build/WEB-INF/logs closely. This is what gave me the final clues. I must be missing one step? You are very close. helena Torsten Torsten Stolpmann wrote: Helena Edelson wrote: With things as they are now in my test, if my browser is on language n, the document (lang n) is served but I haven't gotten it to also to tabs and menues yet I see on other forrest sites it is working so I think I'm missing one thing. looking at your post again - it is 'menu_es.xml' not 'menus_es.xml' (just to make sure). I'll give an example from our sources (HTH): documentation/content/xdocs/tabs.xml: ... translations/tabs_de.xml: Produkte ... translations/tabs_en.xml: Products ... In my initial test I used the file naming conv index.es.xml and changed it not thinking it made a difference but I shall change it back and see. Please do so. *Do you mean you didn't have to modivy or add anything to sitemap? Exactly. Thanks, Helena No problem. Torsten Torsten Stolpmann wrote: Hi, first of all: Our site at http://www.verit.de is already running in i18n-mode (currently only de and en is supported) using the servlet approach and dynamic language detection using forrest 0.7. I think from your description you are almost there: - Setting project.i18n=true in forrest.properties is the right thing to do. - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this is what we did also and it worked as advertised. - Yes, to my knowledge all your pages have to be translated seperatly. Especially if you want to support 10 or more languages this will make structural changes in your pages cumbersome to maintain. We already suffer from this with just our two languages. The above scheme worked for translating almost everything but some settings defined in skinconf.xml (e.g. the feedback link). Especially we never had to touch anything on the sitemap level. HTH, Torsten Helena Edelson wrote: Hi, It doesn't make sense to have to add this: modify |cli.xconf| and add this line: follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” /> if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1"; exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties| modify |cli.xconf| and add this line: follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” /> I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do:
Re: i18n usage
Torsten Stolpmann wrote: - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). It is quite likely that the docs are at best misleading, or even incorrect. i18n support in Forrest is a long way from complete right now and there is almost no useful documentation (as this thread illustrates). I don't have experience of our i18n, nor do I currently have the time to go through the Forrest code right now to verify your conclusion, but if you have it working this way then I reckon that's a pretty good indication. It being the holidays in much of the world right now feedback may be slow coming. However, I (and probably others) are reading this thread an learning. We'll shout if we see something wrong, otherwise you can assume your work is educating us ;-) Ross
Re: i18n usage
Helena Edelson wrote: I have tabs_(lang-code).xml and menu_(lang-code).xml for each language, yet still the index.(lang-code).xml is the only one returned. Could my issue lie perhaps in the translations/langcode.xml file? I added de,fr,no to what is in the distribution yet even with my browser in de, still no luck with menu, tabs or CommonMessages_de.xml for skin. I must be missing one step? After a good nights sleep I remember some rare cases where restarting the web-application was actually needed to propagate the changes I made. Since I don't see anything fundamentally flawed, trying to restart might be an option here. Regards, Torsten helena Torsten Stolpmann wrote: Helena Edelson wrote: With things as they are now in my test, if my browser is on language n, the document (lang n) is served but I haven't gotten it to also to tabs and menues yet I see on other forrest sites it is working so I think I'm missing one thing. looking at your post again - it is 'menu_es.xml' not 'menus_es.xml' (just to make sure). I'll give an example from our sources (HTH): documentation/content/xdocs/tabs.xml: ... translations/tabs_de.xml: Produkte ... translations/tabs_en.xml: Products ... In my initial test I used the file naming conv index.es.xml and changed it not thinking it made a difference but I shall change it back and see. Please do so. *Do you mean you didn't have to modivy or add anything to sitemap? Exactly. Thanks, Helena No problem. Torsten Torsten Stolpmann wrote: Hi, first of all: Our site at http://www.verit.de is already running in i18n-mode (currently only de and en is supported) using the servlet approach and dynamic language detection using forrest 0.7. I think from your description you are almost there: - Setting project.i18n=true in forrest.properties is the right thing to do. - In contradiction to the documentation try naming your web pages index.es.xml instead of index_es.xml. We got that from studying the error logs closely and suspect the documentation is plain wrong here. Can someone from the dev team comment on this? We also renamed our default language files accordingly (index.en.xml in your case). - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this is what we did also and it worked as advertised. - Yes, to my knowledge all your pages have to be translated seperatly. Especially if you want to support 10 or more languages this will make structural changes in your pages cumbersome to maintain. We already suffer from this with just our two languages. The above scheme worked for translating almost everything but some settings defined in skinconf.xml (e.g. the feedback link). Especially we never had to touch anything on the sitemap level. HTH, Torsten Helena Edelson wrote: Hi, It doesn't make sense to have to add this: modify |cli.xconf| and add this line: follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” /> if you are in a live web environment - if you need mulitiple languages. If forrest.properties setting is project.i18n=true, and a user-client browser is language n, is it only that we need to create all the catalogues, menus and tabs for x lanuages we will support and the browser does the rest - i.e. translate the document portion of the page ? Also I can not find anything difinitive on modifying sitemap to handle i18n I see forrest.xmap does a few things, I see the F7 site2html.xsl includes xmlns:i18n="http://apache.org/cocoon/i18n/2.1"; exclude-result-prefixes="i18n" in the xsl:stylesheet declaration so I am not sure what a dev needs to do on the config side, as it seems most of the work is done already in the guts of forrest itself. thank you, helena Helena Edelson wrote: Hi, I tested the i18n features of forrest-0.7-dev - made a new dir - fresh forrest seed - turned forrest.i18n on - added index_es.xml to .../xdocs/ - (menu_es.xml, languages_es.xml, tabs_es.xml in distro) - index.xml file was renamed index_es.xml modified index_es.xml to display some Spanish text Cheche's blog suggests to do this which I did as well: |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties| modify |cli.xconf| and add this line: follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” /> I looked in my build/tmp/projfilters.properties and found that even though I set project.i18n=true in forrest.properties, ant projfilters.properties output is project.i18n=false. Why might this be? My index_es.html is served (locale in browser set to 'es') yet the menu_es.xml does not. I know from mail-archives and others that translation of both menu and doc can work. embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something
Automatic translation of content (Re: i18n usage)
Helena Edelson wrote: embarrasing question: Is it the case that if we want multiple languages to be supported, we have to supply the translations per document page? Nothing will automatically translate for the app like how the online translation engines do it? Would be great to plug something like that in and simply do: Embarrasing, why? It's a great idea. Forrest doesn't do this, but an plugin that retrieved the content from a translation engine would be a great contribution. Of course, the translations would be less than perfect, but it is better than nothing. If anyone wants to tackle this it's a great dev topic (and fairly easy to do with guidance). Ross
