Some developers have had the brilliant idea of using non-standard and conflicting locale codes in their apps. The problem is that, in the case of es_LA (according to ISO "Spanish for Laos", but actually used for "Spanish for Latin America").
I wouldn't file a bug here if it weren't because this is now quite spread and common practice (you'll get that from Facebook's API or in free software localization files).
On the one hand, special handling for this case could be added ("LA" is not Laos if preceded by "es"). On the other, "Latin America" is not a country, and as such it lacks 2-digit ISO code. But it does have a 3-digit UN M.49 supranational code.
I'm not sure what would be an appropiate way of handling this in nv-i18n. At the moment, I'm just getting around it by replacing "es_LA" by just "es" before feeding it to nv-18n.
Some developers have had the brilliant idea of using non-standard and conflicting locale codes in their apps. The problem is that, in the case of
es_LA
(according to ISO "Spanish for Laos", but actually used for "Spanish for Latin America").I wouldn't file a bug here if it weren't because this is now quite spread and common practice (you'll get that from Facebook's API or in free software localization files).
On the one hand, special handling for this case could be added ("LA" is not Laos if preceded by "es"). On the other, "Latin America" is not a country, and as such it lacks 2-digit ISO code. But it does have a 3-digit UN M.49 supranational code.
I'm not sure what would be an appropiate way of handling this in nv-i18n. At the moment, I'm just getting around it by replacing "es_LA" by just "es" before feeding it to nv-18n.