2009/10/29 Antonio Petrelli <[email protected]>: > 2009/10/29 Claude Brisson <[email protected]>: >> On jeu., 2009-10-29 at 09:22 +0100, Antonio Petrelli wrote: >>> 2009/10/28 Nathan Bubna <[email protected]>: >>> > One question, would it make sense to also add a: >>> > >>> > public String toLocalizedPattern(String format) { >>> > return toLocalizedPattern(format, getLocale() >>> > } >>> > >>> > for completeness? Or is that redundant? >>> >>> IMHO this method would be useful too, as long as "getLocale" returns >>> the currently-selected locale, IOW the client's locale. >> >> That's the server locale by default elsewhere in such localized methods >> (or, if present, the one defined in tools.xml). For consistency, I'd >> rather keep it the same here. > > If it's question of compatibility I agree, but you should consider > that, in fact, the server locale is completely useless.
No, it.s not useless, maybe rare. If my company users/partners are spread around the world, I want to force our locale regardless what locale thay have on their borrowed/localy purchased computer... ...Just a thought... > I am Italian and I wish to see pages in Italian (preferably) and dates > in Italian format. > Now, if the server is in Germany, I don't want absolutely to see > "Oktober" as the current month :-D it makes no sense. > However I admit that, getting the client's locale from DateTool might > be problematic, because it should be independent from a Servlet-based > application. The locale can be easily got from the request (or other > mechanisms). > So, at the end, probably the method without the locale should not be > added, to avoid confusion. > > Antonio > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Tomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
