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. 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]
