Yes. The i18n implementation of web application is more complicated than normal desktop applications, since it means single running web application instance can support multiple languages and locale conventions. So the spec may be complicated too, and hard to understand by committers. May be it’s a good idea to introduce a global accessible utility class that encapsulate the logic of the spec. Thus other committers can care little about it, just use it and get right results.
-----Original Message----- From: Anil Gangolli [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 10:46 PM To: [email protected] Subject: Re: ROL-1413: A patch to address some Roller i18n problems Thanks Miles. I saw this on the JIRA. We do have issues with non-uniform treatment of locale and timezone in different places in the app. Yes, most or all of the committers are working in English, and I think we've had ups and downs in how well internationalization has worked. I think what we need to do to achieve proper internationalization is writing and vetting a careful spec of our treatment of locale, timezone and related text formatting, and then to write some unit tests that make sure we don't keep breaking it. We have had stabs at a spec for locale and timezone written down in the past, but I'm not sure where they are now. --a. ----- Original Message ----- From: "Miles" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, May 15, 2007 7:09 AM Subject: ROL-1413: A patch to address some Roller i18n problems > > Hi Roller developers, > > Thanks for your excellent working, produced out an excellent interactive > web > site platform. > But is it only for people speaking English? Just kidding ;-). > > Roller uses many ways to find locale for i18n messages. Consider following > methods to get a locale: > Locale.getDefaultLocale(), > request.getLocale(), > RollerSession.getRollerSession(request).getAuthenticatedUser().getLocale() > For a real web site for global users, it's quit common that all these > locales have different values. > Current codes use all these different locales to get i18n message, which > leads to different languages even on a single page. > More important, the Locale.getDefaultLocale() return server JVM's default > locale, which is considered leading web application unportable and should > be > avoid in J2EE web applications. As JSTL ResourceBundle lookup algorithm > have > make special change against the standart J2SE ResourceBundle lookup > algorithm. Unfortunately many i18n translated message in roller is > generated > according to it, especially in rendering system. > > Detailed information of critical i18n problems has been posted to JIRA as > http://opensource.atlassian.com/projects/roller/browse/ROL-1413 ROL-1413 , > with a patch file to address them. > There should be more i18n related issues which are more obscured to > discover. I'd like to dig more into it later. > > Regards, > Miles. > > -- > View this message in context: > http://www.nabble.com/ROL-1413%3A-A-patch-to-address-some-Roller-i18n-problems-tf3758693s12275.html#a10623568 > Sent from the Roller - Dev mailing list archive at Nabble.com. >
