Jump to content

Multiple currency format for one language pack.


Luis

Recommended Posts

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.

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...