Re: I18N by pages
Hello, Maybe another idea if I understand well what you want. So you want to include a file, specific to the current locale definition. I need about the same feature, and was looking for a better way than mine to solve this. The only think is that I include a i18n _file_ in a general template, and i do not redirect the user direclty to this i18n file. You have only one tiles-def.xml, one struts-config.xml, one properties file per locale. The idea is to have the file name locale-specific (so stored in properties file), and to call the file via the properties file, so the correct, locale-specific, name is called. It gives : In the main file, where i include, i have, in state of simple tiles:insert attribute=.../ : jsp:include flush=false jsp:attribute name=page tiles:getAsString ignore=true jsp:attribute name=name i18n:message bundleRef=help key=help/ /jsp:attribute /tiles:getAsString /jsp:attribute /jsp:include Than, I have somewhere in my tiles_def.xml something like : put name=help value=custom.help/ And in my properties file (locale specific) something like custom.help=../help/customHelp_en.jsp and for another language, I have custom.help=../help/customHelp_fr.jsp Than, i need to modify the last line, and to specify it differently in my properties files, for all my locales. But i can have a different file per locale. Maybe this can be adapt at your specific needs. On the other way, maybe there's a better way to do this that mine ... ? Of course, something great would the use of tiles:insert baseName=... locale=... / ! Hope this can help someone ... On 29/06/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello! Jeff Beal wrote: ... Have you considered locale-specific CSS files to give a different presentation to the same JSP page? ... I have no idea of this. Can you, please, comment? Yaroslav Novytskyy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Marc Demlenne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Just a small mistake while copying my code here ... I've swapped to things. Sorry It is : jsp:include flush=false jsp:attribute name=page i18n:message bundleRef=help jsp:attribute name=key tiles:getAsString ignore=true name=help/ /jsp:attribute /i18n:message /jsp:attribute /jsp:include On 11/07/05, Marc Demlenne [EMAIL PROTECTED] wrote: Hello, Maybe another idea if I understand well what you want. So you want to include a file, specific to the current locale definition. I need about the same feature, and was looking for a better way than mine to solve this. The only think is that I include a i18n _file_ in a general template, and i do not redirect the user direclty to this i18n file. You have only one tiles-def.xml, one struts-config.xml, one properties file per locale. The idea is to have the file name locale-specific (so stored in properties file), and to call the file via the properties file, so the correct, locale-specific, name is called. It gives : In the main file, where i include, i have, in state of simple tiles:insert attribute=.../ : jsp:include flush=false jsp:attribute name=page tiles:getAsString ignore=true jsp:attribute name=name i18n:message bundleRef=help key=help/ /jsp:attribute /tiles:getAsString /jsp:attribute /jsp:include Than, I have somewhere in my tiles_def.xml something like : put name=help value=custom.help/ And in my properties file (locale specific) something like custom.help=../help/customHelp_en.jsp and for another language, I have custom.help=../help/customHelp_fr.jsp Than, i need to modify the last line, and to specify it differently in my properties files, for all my locales. But i can have a different file per locale. Maybe this can be adapt at your specific needs. On the other way, maybe there's a better way to do this that mine ... ? Of course, something great would the use of tiles:insert baseName=... locale=... / ! Hope this can help someone ... On 29/06/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello! Jeff Beal wrote: ... Have you considered locale-specific CSS files to give a different presentation to the same JSP page? ... I have no idea of this. Can you, please, comment? Yaroslav Novytskyy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Marc Demlenne -- Marc Demlenne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Hello! Jeff Beal wrote: ... Have you considered locale-specific CSS files to give a different presentation to the same JSP page? ... I have no idea of this. Can you, please, comment? Yaroslav Novytskyy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
This is just an idea, depending on what sort of differences you have
on your JSP pages, it may or not work. As a trite and unrealistic
example, let's say that your design team has told you that blue text
will work better for your English-speaking audience, but purple text
will work better for your French-speaking audience. Simply create two
stylesheets:
lang_EN.css:
body { color: blue; }
lang_FR.css:
body { color: purple; }
Then, in your JSP page, you'd just include the appropriate
locale-specific CSS stylesheet to achieve the look you want. (sounds
like a really quick custom tag.)
I'm sure that color is not the extent of the differences between what
you would want in your French-specific JSP's and your English-specific
JSP's, but with all of the positioning and other capabilities in CSS,
you could probably do a lot with this approach.
On 6/29/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote:
Hello!
Jeff Beal wrote:
...
Have you considered locale-specific CSS files to give
a different presentation to the same JSP page?
...
I have no idea of this. Can you, please, comment?
Yaroslav Novytskyy.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Wow! meanwhile I've had the same idea. Posted simultaniosly :) But I doubt, that this solution will be compatible with tiles :( What do you think about that? Don't use tiles. :-) I'm serious. I used tiles for several years quite successfully. For my most recent project I switched to using the SiteMesh decoration via response filter approach. I can imagine there are some complex page layout webapps where Tiles might work better. For a standard webapp with a header/navArea/content/footer breakdown, SiteMesh is more than sufficient and *way* simpler to configure than the tiles approach. Unless you have a huge investment already in using Tiles, I recommend checking out SiteMesh as an alternative that would be compatible with the custom ActionMapping approach suggested by Jeff. You can see an example of SiteMesh in the Equinox simple webapp starter project put together by Matt Raible. Google Equinox Raible to look it up on the web. . -Van -- - Mike Van Riper [EMAIL PROTECTED] Best regards Yaroslav Novytskyy Jeff Beal wrote: Probably your best bet would be to use a custom ActionMapping and override the findForward() method to return a Locale-specific JSP page. On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I18N by pages
Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. Martin Gainty wrote: Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Probably your best bet would be to use a custom ActionMapping and override the findForward() method to return a Locale-specific JSP page. On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. Martin Gainty wrote: Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
I'm confused here. You have 2 resource bundles called: resource_fr.properties resource_en.properties They both have the same keys but different values. The Struts framework will load the appropriate value from the correct bundle based on the locale language. That's it !! One jsp can obtain all of its string values from the bundle. In your example, you had mentioned that you'd like the title to be different based on the locale. You can also include the HTML in the resource file but IMHO this not the most efficient way. French is usually more verbose than English. At times the HTML page must be really different to accomodate the French. In general, I always design the page in French first as for it will work out fine in English afterwards. - Glenn [Martin: très bien !] On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. Martin Gainty wrote: Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Hi! Yes this is a possibillity. But what if I already have different forwards for my action: success, info, lalala. I will have to change this to success_en, info_en, lalala_en and to add success_fr, info_fr, lalala_fr and to include additional logic to action to check what language is requested by user. This logic can be extracted to all actions base class. But what if I would like to include new languages? Normal step I would like to perform is just to create new (approprietly named) jsp's not to rewrite the whole struts-config and to add lots of new forwards: success_es, info_es, lalala_es, like this. Here I can propose to override mapping.findForward or somehow like this... In this case findForward would check the user requested language, find a forward path add/insert locale suffix and return link to file. Please comment, what do you think about this? Best regards Yaroslav Novytskyy P.S. this will be not compatible with tiles :( Glenn Deschênes wrote: What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Wow! meanwhile I've had the same idea. Posted simultaniosly :) But I doubt, that this solution will be compatible with tiles :( What do you think about that? Best regards Yaroslav Novytskyy Jeff Beal wrote: Probably your best bet would be to use a custom ActionMapping and override the findForward() method to return a Locale-specific JSP page. On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. Martin Gainty wrote: Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Hi! French is usually more verbose than English. At times the HTML page must be really different to accomodate the French. In general, I always design the page in French first as for it will work out fine in English afterwards. French was only an example, I think of Ukrainian instead, but didn't want to mention it since it could be confusing for the community :) Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
Yaroslav, You just threw in Tiles into the mix ! Can't suggest anything haven't used it yet. Perhaps you can rephrase exactly what you'd like to do and use. - Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Wow! meanwhile I've had the same idea. Posted simultaniosly :) But I doubt, that this solution will be compatible with tiles :( What do you think about that? Best regards Yaroslav Novytskyy Jeff Beal wrote: Probably your best bet would be to use a custom ActionMapping and override the findForward() method to return a Locale-specific JSP page. On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. Martin Gainty wrote: Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N by pages
I haven't looked into the guts of how forwards to Tiles definitions work, but I think the basic idea is still sound. It's just that the path attribute of your forward is now the name of a Tiles definition instead of a JSP page, so in addition to a separate JSP page for each supported locale, you'll also need a separate Tiles definition for each locale. That's starting to look like a lot of duplication of effort, though. If you have a lot of pages and intend to support a lot of languages, you're looking at a lot of different JSP pages and a massive tiles configuration. Have you considered locale-specific CSS files to give a different presentation to the same JSP page? On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Wow! meanwhile I've had the same idea. Posted simultaniosly :) But I doubt, that this solution will be compatible with tiles :( What do you think about that? Best regards Yaroslav Novytskyy Jeff Beal wrote: Probably your best bet would be to use a custom ActionMapping and override the findForward() method to return a Locale-specific JSP page. On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hi! This is exactli what I'd like to avoid and use l10n on pages level not level of defined strings in message bundles for different languages. I don't want to use the english (html) design and to translate english phrases to french, which will be included into english design. I want to use french _page_. That meens french design with includes french text - standalone french jsp. Martin Gainty wrote: Glenn et al Another option for Struts localisation is to embed your language specific strings typically with key=string defined within your ApplicationResources_language_country.Properties file struts-config.xml will reference message-resources for key-based tag or param-value (initialisation param) for your servlet for ApplicationResources (properties) file When these elements are configured properly in struts-config.xml then your bean-write will work with html-messages Take a look at this excellent tutorial located at http://www.systemmobile.com/articles/strutsMessageResources.html#creating-bundle Bon Chance, Martin- Etats Unis 001-617-852-7822 - Original Message - From: Glenn Deschênes [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Friday, June 24, 2005 9:52 AM Subject: Re: I18N by pages What you can do is have a jsp for each locale language such as page_fr.jsp and page_en.jsp. Your application can store the locale in the user's session object. Your application can update the session locale when the user switches between en fr. You can have the following forwards for the action in the struts-config.xml: forward name=en path=/WEB-INF/page_en.jsp /forward forward name=fr path=/WEB-INF/page_fr.jsp /forward In your ActionForm you can: return mapping.findForward(get the locale language from the session); HTH, Glenn On 6/24/05, Yaroslav Novytskyy [EMAIL PROTECTED] wrote: Hello, all! I just wonder if there is an existing (tested, prooved) way (a kind of development pattern) for Struts to make internationalization not by message resources but by pages (JSPs, templates)? The point is that using message resources deleloper can only define a string value for different locales. For example for en welcome=aaa for fr welcome=bbb, and you include it like titleout welcome/title. This produces titleaaa/title for en and titlebbb/title for fr. That makes you limited to localizing only strings, but not the format. E.G. I would like to output titleaaa/title for en and h1bbb/h1 for fr. And this not the matter of defining this strings (h1bbb/h1) in message bundles, but I would like to use separate JSPs for en and fr and that is the point. I would like have two jsp files: page1.en.jsp with content of titleaaa/title and page1.fr.jsp with h1bbb/h1. (P.S. this reduces much (maybe even terminates) the mess with message bundles). Please write all your suggestions and thoughts. Best regards Yaroslav Novytskyy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: I18N by pages
Yaroslav, Tiles already contains 18N support. If your tiles config is called tiles-config.xml, the controller will look for tiles named in the user's locale first (tiles-config_fr.xml, tiles-config_de.xml) and then default to the original if cannot be found. Use this as a way of presenting different views to the user based on the locale. Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
