Hmm... the server-side converters do use the currently set locale - so
they should support localization and I18n!
regards,
Martin
On 3/12/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hey Bob,
yes, there is a dojo,number package and since tomahawk already uses dojo,
i think it's fine to
I believe there is i18n work going on in the dojo project. Any thoughts of
incorporating that effort?
Hi Mario,
Good catch, I was thinking about localization before but I left it for
later for now. Because it seems like the server side converters like
javax.faces.FloatConverter or
Hi Cagatay!
Good catch, I was thinking about localization before but I left it for
later for now. Because it seems like the server side converters like
javax.faces.FloatConverter or javax.faces.DoubleConverter do not
handle i18n too. I'm trying to make the client side validation be %100
Hey Bob,
yes, there is a dojo,number package and since tomahawk already uses dojo,
i think it's fine to take that as well.
-M
On 3/11/07, Bob Gallagher [EMAIL PROTECTED] wrote:
I believe there is i18n work going on in the dojo project. Any thoughts of
incorporating that effort?
Hi Mario,
Hi Cagatay!
+ var doubleRegExp =
/^(\+|-)?\d*\.?\d*([eE]\d+)?[dD]?$/;
I haven't had a look at all your validation code, though, do it deal
with i18n?
Means, the regexp above allows to have a . - I guess as fraction
delimiter. But then, this depends on language
Hi Mario,
Good catch, I was thinking about localization before but I left it for later
for now. Because it seems like the server side converters like
javax.faces.FloatConverter or javax.faces.DoubleConverter do not handle i18n
too. I'm trying to make the client side validation be %100 compatible
Just a quick typo fix:)
as an example Float.valueOf(10,2) everytime even in French locale
as an example Float.valueOf(10,2) fails everytime even in French locale
Cagatay
On 3/11/07, Cagatay Civici [EMAIL PROTECTED] wrote:
Hi Mario,
Good catch, I was thinking about localization before but
