[908B64B197]

One nitpick about localization:

If you speak several languages, try setting your device to use one _language_ and keep your locale to US.

Now you can spot which developer understands the difference between a language and a locale and which one doesn't (hint: on large enough apps you'll land on pages using the wrong one, ie determines the language using locale). Or the opposite (watch the UI quote you prices in Euro despite your locale being USD).

[dataflow]

If someone sets the language to (say) French but keeps their locale as English, do you write a thousand as 1,000 or 1.000? What about the reverse case?

[908B64B197]

Congratulation: You just opened the Pandora box of locale vs language!

My understanding would be that locale should dictate numerical formatting. But one could argue the opposite and also be right.

[PaulDavisThe1st]

If you were discussing POSIX locale, the definitions are quite clear, and there's no ambiguity. But that's also because POSIX subdivides locale into many subsections.

From "man setlocale":

       LC_ALL              All of the locale

       LC_ADDRESS          Formatting of addresses and
                           geography-related items (*)

       LC_COLLATE          String collation

       LC_CTYPE            Character classification

       LC_IDENTIFICATION   Metadata describing the locale (*)

       LC_MEASUREMENT      Settings related to measurements
                           (metric versus US customary) (*)

       LC_MESSAGES         Localizable natural-language messages

       LC_MONETARY         Formatting of monetary values

       LC_NAME             Formatting of salutations for persons (*)

       LC_NUMERIC          Formatting of nonmonetary numeric values

       LC_PAPER            Settings related to the standard paper size (*)

       LC_TELEPHONE        Formats to be used with telephone services (*)

       LC_TIME             Formatting of date and time values

[conductr]

Not to disparage the conversation the technical bits are certainly interesting but, for almost every application, this is the point where things move towards diminishing returns. You could invest infinitely into getting every bit of design and copy for every language and locale permutation flawless and you’re company would be worse off because you should have spent that time elsewhere. In many cases, it’s simply not unrealistic to expect your customer to use google translate.

[Vinnl]

If we're opening Pandora's boxes...

I've got GNOME set up in English, but my region to be the Netherlands. It will helpfully display local dates, but that also results in the month names being in Dutch.

[account42]

Maybe that's what the Gnome interface limits you to (no idea) but LC_TIME and the timezone are not inherently linked under Linux.

If by "local dates" dates you mean the format rather than timezone then LC_TIME=en_DK will give you English text with RFC3339 YYYY-MM-DD formatting.

[Vinnl]

Unfortunately I don't really know what LC_TIME is :) But if I look through the calendar widget that drops down when I click the time in the top bar, is says e.g. that the previous month is called "augustus" and that today is "vrijdag". Looking into my "Region & Language" settings, my language is set to English (United Kingdom), and formats is set to Nederland (Nederlands), which is said to cover numbers, dates and currencies. Especially for currencies I'd prefer my local currency, but I'd prefer for numbers to use the UK system, and not quite sure what I'd like for dates as long as it's not the US system.

[pjscott]

I checked the documentation for the ICU Unicode library and Apple's Foundation library, and they both say that numerical formatting is a property of the locale rather than the language. I'd be surprised if other major platforms did otherwise.

[dataflow]

Yeah my understanding is people would classify this as locale too, but it's always seemed weird to me. I guess my question is whether this is about formatting to begin with. Periods mean something different depending on the language, right? It seems less about displaying it differently and more about conveying correct information. But then again, mm/dd/yy and dd/mm/yy are often exposed as a formatting option...

[marcosdumay]

Ouch. If you are writing user interface for something that doesn't need to be "correct" (legally, or whatever), I find it best to accept whatever decimal separator (what you want, or change by locale, or both, whatever), and never use or allow thousands separators. Bonus points if you document it somewhere on the interface.

If you really, really, really need a thousands separator, use spaces.

[r00fus]

Locale would be a country so e.g. UK? Then it'd be just like the US (1,000).

[squeaky-clean]

This is correct, but if we're being pedantic (it is HN after all) the locale code for the UK is "gb". The language / locale would be fr-gb.

I work on this sort of thing for airline ticketing pages. fr-gb would mean the customer wants the page text to be in French, but they want to buy a ticket using the UK system (i.e. Using GBP instead of EUR as the currency if possible, and all the formatting differences that would be specific to "gb").

Quick edit: technically I guess your locale doesn't have to determine your store region, that's just how we do it. As far as I know there's nothing except development effort preventing us from allowing someone to book a flight in French, using GB locale, and with preference for the Japanese point-of-sale system.

[Symbiote]

I really appreciate websites that allow me to use "Denmark - English" and see prices and payment options I understand, in the language I understand best.

[david_allison]

locale defines decimal formatting

[zapzupnz]

I got stuck with this a few years ago. I live in New Zealand. My bank used iOS’ number pad keyboard to let me enter a deposit amount in its app.

When I switched my phone to French language but left the region and formatting as English (New Zealand), it was clear the app developers didn’t know the difference between language and locale because suddenly I couldn’t deposit amounts with a decimal point; they didn’t account for the fact ‘,’ would show up on the number pad rather than ‘.’.

It meant that they detected my phone’s language rather than locale. It used French’s locale settings for the decimal separator despite the fact I had specifically set my locale settings to remain in English (New Zealand).

I complained and it was later fixed to detect locale instead — but seriously, language vs locale, not rocket science.