2009/10/29 Claude Brisson <[email protected]>: > On jeu., 2009-10-29 at 11:02 +0100, Antonio Petrelli wrote: >> 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. > > A tools.xml defined locale (either globally or by tool) would make some > sense. This feature is already available in tools 2.0.
Uh right, never mind :-) Antonio --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
