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. Claude --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
