Culture code

[ArmorDarks]

First of all, I don't want to offend anyone. I'm really very grateful for such great lib, it helped us to solve a lot of problems. Thanks!

I do understand that probably this issue won't change anything, since it's, obviously, too late, and seems to be in accordance with numbro's team visions.

But anyway, my two cents.

Why it has been decided to rely on culture term? In most part of i18n community used term locale (probably, thanks to GNU efforts).

I'm working as Translation Coordinator and i18ning some apps for about year or two, but never heard about culture code before. Obviously, I've probably came across it somewhere, since I've often used Microsoft tables with locale codes. But since locale term was so popular till that time I've never realized that Microsoft actually used culture code instead of locale.

I think it would be logical to use culture code if numbro was somehow related to Microsoft's products, but it isn't that case, and in Node community it isn't well know term, since all popular i18n libs operate with term locale:

• https://github.com/SlexAxton/Jed
• https://github.com/andris9/node-gettext
• https://github.com/SlexAxton/messageformat.js
• http://i18next.com/
• http://l20n.org/

From my personal point of view, Microsoft invented culture as result of fatal flaw of locale term, despite everywhere in i18n community were used locale or language code terms, and its naming very confusing, since has nothing to do with culture. It consists of {language code} and {region code}. Does it represent any culture, which can be many in specified `{lang-Region}? Obviously no.

[seckin206]

I do understand that probably this issue won't change anything, since it's, obviously, too late, and seems to be in accordance with numbro's team visions.

Developers listen to other developers, so there is always room to improve.

I think I was the primary force pushing for the adaptation of culture and deprecation of language. The essential idea is that there is no way to unambiguously define language without considering the region it is spoken. We clearly adopted Microsoft terminology, but I think it is substantially less ambiguous than setting language to Portuguese and getting Brazilian Real as currency.

[ArmorDarks]

Thanks for reply

I'm totally supporting implementation of culture instead of plain language, it's definitely much more superb and right direction.

But issue isn't about it, it's relayed only to terminology itself

Microsoft's culture is same thing as locale, which in most cases implementation of BCP 47, which basis on few common-accepted ISO standards. I assume Microsoft had to invent new term to distinguish from concurrent UNIX platforms (from which locale term originated).

However, as I pointed out, Microsoft culture isn't as common as locale term, and even misleading in some cases.

I mean, that you can swap numbro.setCulture method name with numbro.setLocale (or even make them aliases) and everything will work as expected, but setLocale will be more understandable to most Node developers.

[seckin206]

locale(not in our library, but if you take it as an independent term) encapsulates things like paper size, case conversion rules, and string collation etc. I think it is perfect for setting up your operating system, on the other hand it seems unnecessarily wide(so misleading) in terms of scope when setting up your number formatting library.

[ArmorDarks]

locale encapsulates things like paper size, case conversion rules, and string collation etc.

It's ISO-based identifier of user's language and region. It nor doesn't, nor should contain anything inside — it's up to software to determinate what will it expose, mean, how will be interpreted, etc.

I'm becoming self repeating, but what you call culture and what you have already implemented is same as locale, it's just Microsoft's name for same boat.

In fact, Microsoft used locale in their own tables for quite a long time, and still continuing to use:

• https://msdn.microsoft.com/en-us/goglobal/bb964664.aspx
• https://msdn.microsoft.com/en-us/goglobal/bb688174.aspx
• https://msdn.microsoft.com/en-us/library/windows/desktop/dd318716(v=vs.85).aspx

But in later Microsoft guides interpetation has changed, they started to merge term locale with region or country: https://msdn.microsoft.com/en-us/library/bb975829.aspx

That's where culture term probably came — because of wrong interpretation of locale, which originally meant language code + region code, not just region code.

[BenjaminVanRyseghem]

Another point to take into consideration is that our server is written in C#, thus using culture code :smile:

when we started this fork, it was "for us only" so to speak.

Beside that, I feel the term "Culture code" to be less ambiguous.

This said, I have no issue changing it to "locale" as it's just a terminology issue.

This have to be solved before we change the public API :smile:

[ArmorDarks]

Ah, I see. Well, we have somehow to respect both worlds.

I'd propose compromise in form of numbro.setLocale alias for numbro.setCulture.

I just didn't see purpose to introduce terms, which is uncommon in JavaScript community. Here and there JS users will pass in usual to them locales in setCulture with hope that it's what they were looking for. Fortunately, it will work.

Why would they do that? Because every other JS library using locales, like close by the spirit to numbro moment.js.

Consistency for the win.

Anyway it's up to you. If everything will remain as it is, nobody gonna die :)

Thanks for great work once again!

[adamgruber]

👍 for locale

Easiest fix would be to alias things so as not to be a breaking change.

[ArmorDarks]

I think the only issue here, is, as far as I know, Microsoft's culture code doesn't allow cultures, which consists only from language code.

In GNU locales such examples are en, de or ru, which by default are acceptable locales and will stand for de_DE and ru_RU. en seems to be quite unique, since it the only one which stand for en, which is region-less.

Here is table of locales from Debian. You can see that for most generic languages already predefined specific, most common region. Like ar_SA for ar.

In Microsoft's culture they should be always written with region, in other words, de or ru is wrong culture codes, and de-DE and ru-RU are ok. Though, I might be wrong about it.

[ArmorDarks]

Hi guys! This discussion happened quite a while. Any movements on this? :)

[BenjaminVanRyseghem]

@ArmorDarks I think locale is a better choice (more GNUish :smile:)

[ArmorDarks]

Hi :)

I think it might be reasonable to leave setCulture and add setLocale. As you explained, setCulture doesn't allow culture codes of loose type (like ru instead of ru-RU), while setLocale allows this. So developers could choose more appropriate for their situations behavior.

[BenjaminVanRyseghem]

indeed :smile:

[gwynjudd]

Hello,

I'm a bit late to this discussion, but it seems like the concensus is that locale and culture should be synonyms in the code? In that case, should these deprecation warnings be removed?

e.g. https://github.com/foretagsplatsen/numbro/blob/b2c22217448d714f1548a55cedab6ba546bfae1c/dist/numbro.js#L742 https://github.com/foretagsplatsen/numbro/blob/b2c22217448d714f1548a55cedab6ba546bfae1c/dist/numbro.js#L789

there are many other examples. Should the culture methods & properties be made true aliases?

[BenjaminVanRyseghem]

I will try to do a clean up and use locale everywhere as it's more GNU-ish than culture :smile: