New answers tagged

1

C#and javascript both have a few good tools for converting number formats... if you can get the country/language iso code from the user or site (eg "de-DE" for Germans), this is easy to do... C#, for instance, has the CultureInfo class for this purpose... User goes to your site (eg. with "/de-DE/" somewhere in the URL) User enters his value in his format ...


0

On the input side I would leave the thousand separator, and allow only numbers and decimal separator based on the language settings of the current user, but store the values in a unified way eg: allow 1000.0 (as 1000) and store as 1000.0 allow 1000,0 (as 1000) and store as 1000.0 On the output side you can again rely on the language settings. And can ...


1

One way to resolve this is to not make people enter decimal periods. Reject any non numeric input and let people choose the unit (meter, centimeter, etc). For dates, use a date picker rather than a textbox. The risk of using user's locale setting is that if people are sharing information (e.g. in support forum/wiki) about how to enter fractional inputs, ...


2

Regarding input: do your users really need to type thousand separators manually? If no (which is the most likely case), I would treat both . and , typed into the field as a decimal point and allow only one symbol of that kind for that value. Regarding output of the values: IMHO, it is better to rely on OS formats by default, but to provide possibility to ...


1

According to the Wikipedia entry on high/low context cultureL In a higher-context culture, many things are left unsaid, letting the culture explain. Words and word choice become very important in higher-context communication, since a few words can communicate a complex message very effectively to an in-group (but less effectively outside that ...


0

In my experience from English to Spanish your layout and design patterns need to be extremely fluid. Things like product description, prices and other content elements seem to take more real estate. This of course will vary from language to language.


2

Depends on the audience, and secondarily on the subject matter. If it has been determined, or it is presumed, that the audience would not be disconcerted by the presence of multiple languages on the same page, whether or not they are able to read every one of them, then at worst there is no disadvantage in doing this. At best it makes life easier for those ...


1

We have faced the similar issue recently. We deal with client from multiple timezones & everyone wants date to be displayed in their own formats in reports. So we ask for default date display format on creation step & display date accordingly on every report. For a date which is meant to be consumed by a user only, I think it's best to spell out the ...


0

I'm a proponent of using ISO dates (YYYY-MM-DD) because this ambiguity is so annoying. This is generally understood, though it is not hugely common outside technical applications. Even if it is not the most widely used way of displaying dates, I think it is worth pushing because it is a clearly superior solution. It also has the virtue of resulting in ...



Top 50 recent answers are included