Results 1 to 9 of 9

Thread: Advice Needed: multilingual versions of web application

  1. #1

    Default Advice Needed: multilingual versions of web application

    Here is my current task: to build a multilingual versions of web application with Spring. The presetation (view) will use JSP. One language is English and the other is non-Western language. The difference between the various language versions only is in the V(iew) largely. Another difference in the business layout is that the user input string data type needs to have suitable encoding for the non-English version. I have two approaches (I can think of).

    1. Two sets of JSP file: one for English the other for the other language as the BluePrints' PetStore
    2. having a single set of JSP file and using message bundle

    I would like to have the second approach for the easy maintanence. A problem with this approach is that I still need multi-version JSP files for long text pages.

    Can anyone share your experience in this regards?

    Thanks.

  2. #2
    Join Date
    Aug 2004
    Location
    Auburn, AL, USA.
    Posts
    106

    Default

    I'd say mix the two approaches: for form type pages use one JSP w/ message bundles; for text type pages use the ResourceBundleViewResolver.

    Just a wild idea, but it would be very cool if there was a way to support Apache (httpd) style Multiview/Content-Negotiaton: http://httpd.apache.org/docs-2.0/con...gotiation.html ; specifically it would be nice to be able to default from the user's most prefered language to a less prefered language rather than simply one default language.

    Just my two cents.

  3. #3
    Join Date
    Aug 2004
    Location
    Hong Kong
    Posts
    26

    Default

    Spring uses AcceptHeaderLocaleResolver by default, which just works! There are some more i18n support classes that you may find useful in the same package (org.springframework.web.servlet.i18n).

  4. #4
    Join Date
    Aug 2004
    Location
    Auburn, AL, USA.
    Posts
    106

    Default

    The problem with AcceptHeaderLocaleResolver, and anything else that uses Locale is that a user may have multiple languages specified in their "accept-language" header. Basically I ran into a design where it would be very benifical to work the way down a list of possible locales rather than having only one. That said, for the most part a single Locale is often all you need.

  5. #5

    Default

    Thanks both for your response.

    It seems that I didn't make my project clear. The application has multilingual versions, but each installation is in single language only. The reason behind this decision is that most of data is from user input. With this, no locale detection is needed.

    Lawrence:

    You seem to have worked on i18n application. Do you enter Chinese or the unicode conversion into the message property file? What character set you use in your JSP files?

    BTW, I have built a mulitlingual web application. It displays a language based on either user browser accept-language setting or user account setting. If any of you are interested, I can provide the sit address offline.

  6. #6
    Join Date
    Aug 2004
    Location
    Hong Kong
    Posts
    26

    Default

    If each installation is in single language only, perhaps you can put one set of mesage property files to force Spring or other applications to resolve to that particular set of messages.

    Regarding the contents of the property files, it is better to make sure they are in Unicode or some strange things will happen, e.g. some non-English characters disappear... I use a property editor plugin for Eclipse to have my Chinese characters converted to Unicode on the fly. The same result can be achieved by using native2ascii tool in the JDK or the related Ant task.

    My JSPs are all in English, as all application messages are supposed to be in property files. You may set the pageEncoding for the JSP to, for example, UTF-8 when you need to put some non-English characters there.

  7. #7

    Default

    Lawrence,

    Thanks for the information. I have the following related queestions:

    1) After converted into Unicode, what format of a Chinese character look like: "\ufffd" or "&\#3641;"? (the "\" sign shalln't be between the "&" and "#". I don't know how to have an escape)
    2) Where I can get the Eclipse property editor plugin? I know a such editor on the IBM AlphaWork site. It doesn't work well at the time I tested it.
    3) How to do deal with a large chunk of text? I can't image to have a big chunk of text in a property file.
    4) What character encoding do you use when your application sends Chinese text email out?

  8. #8
    Join Date
    Aug 2004
    Location
    Hong Kong
    Posts
    26

    Default

    1) Should be like "\ufffd". Those are the escape codes for Unicode characters.

    2) I use this one:
    http://www.eclipse-plugins.info/ecli...ils.jsp?id=656

    There are a few others that you may like to try out as well.

    3) Perhaps a few helper classes to identify the suitable locale and load separate plain text files as Spring Resource would work?

    4) No idea, as my applications do not send emails, yet. But I guess UTF-8 is good in general.

    HTH

  9. #9

    Smile

    Hi,

    can anybody post a sample

    JSP + Server side Codes for UTF8 Support


    Thanks ,
    Sudheesh

Similar Threads

  1. Replies: 2
    Last Post: Oct 10th, 2005, 05:12 PM
  2. advice on improving concurrency in application?
    By henderson_mk in forum Data
    Replies: 10
    Last Post: Oct 6th, 2005, 04:33 AM
  3. Compatible versions for spring application
    By mas802 in forum Architecture
    Replies: 1
    Last Post: Sep 27th, 2005, 06:05 PM
  4. Questioning the core component
    By Martin Kersten in forum Swing
    Replies: 6
    Last Post: Feb 21st, 2005, 03:45 AM
  5. Spring with JBoss with no EJB's - advice needed
    By hay7777 in forum Architecture
    Replies: 7
    Last Post: Sep 17th, 2004, 12:51 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •