Multiple currency format for one language pack.

[Luis]

Hi.

I don't know if you're already working on something like this, but I'd like to put out a feature request.

For context: there are 2 flavors of spanish in the settings:

• Spanish -> which defaults to es_ES (for Spain)
• Spanish (Latin America) -> which defaults to es_419 (this being a generic Latin America code).

That's fine, because if a client is inside Latin America, maybe the UI it wil auto detect and switch to that automatically.

The issue comes with currency, specially how currency is displayed in different countries inside Latin America. For example, in some south american countries the thousand separator is (.) instead of (,) but in México and Colombia is the other way arround. Is tricky.

 

My proposal would be to do something in this area (please notice that I'm only talking about spanish, there could be cases for other regions that I don't know about):

1. Detect if the client is in Spain or in Latin America when they're not logged in. (this is especially to avoid having to create a translation in localazy for each country).
2. Apply Spanish for Spain and Spanish (Latin America) for latin american customers automatically.
3. Detect which country are they in (maybe via IP address, seeing that their browsers could be configured to other locale automátically).
4. Set their momentjs locale to the specific locale code for their countries.

And after the client creates an account, save it to their profiles. Maybe even let them change it in case they move or something.

 

Maybe you can even have a map for this situation.

For exmple:

CASE 1

Region for translations:

es_ES

Format code for dates and currencies:

es_ES	Spanish (Castilian)
es_ES	Spanish (Spain)

(I don't know if these are different, but just for the sake of illustration)

 

CASE 2

Region for translations:

es_419

Format code for dates and currencies:

es_AR	Spanish (Argentina)
es_BO	Spanish (Bolivia)
es_CL	Spanish (Chile)
es_CO	Spanish (Colombia)
es_CR	Spanish (Costa Rica)
es_DO	Spanish (Dominican Republic)
es_EC	Spanish (Ecuador)
es_GT	Spanish (Guatemala)
es_HN	Spanish (Honduras)
es_MX	Spanish (Mexico)
es_NI	Spanish (Nicaragua)
es_PA	Spanish (Panama)
es_PE	Spanish (Peru)
es_PR	Spanish (Puerto Rico)
es_PY	Spanish (Paraguay)
es_SV	Spanish (El Salvador)
es_UY	Spanish (Uruguay)
es_VE	Spanish (Venezuela)

 

And that's basically it, sorry for the long post.

I believe this will greatly improve the UI and purchase experience in general and eliminate some weirdness around how highly internationalized stuff is shown.

 

Regards.

[Luis]

This would apply to the front end specially, considering the back end is just us.

But if would be nice if it could apply everywhere.

[Chris]

Hi Luis - so i'm not too sure what we can do here. With language, we simply make a default selection based on the client's preferred browser language, assuming it is also supported by your brand. We intentionally don't do anything based on IP. So if i were travelling and in Peru, I'd personally still want localisation in EN. Currency formatting is then also determined based on your language – so the use of commas or points for example will change based on your current locale. You can see this in action simply by changing your language.

[Luis]

2 hours ago, Chris said:

Hi Luis - so i'm not too sure what we can do here. With language, we simply make a default selection based on the client's preferred browser language, assuming it is also supported by your brand. We intentionally don't do anything based on IP. So if i were travelling and in Peru, I'd personally still want localisation in EN. Currency formatting is then also determined based on your language – so the use of commas or points for example will change based on your current locale. You can see this in action simply by changing your language.

Hi Chris. 

Then the solution would be to add more locales, right?

There are different comma and thousand separator treatment in Latin America depending on the country. 

Is there a way to request a new locale to be supported? 

[Luis]

38 minutes ago, Luis said:

Hi Chris. 

Then the solution would be to add more locales, right?

There are different comma and thousand separator treatment in Latin America depending on the country. 

Is there a way to request a new locale to be supported? 

It would be es_PY. 
Would each new locale require its own translation in localazy?