Users occasionally report that the wrong formatting is used for several non-existant locales including Mexican English (en-MX) and Brazilian Spanish (es-BR). We should document that since these locales don’t exist, they would fall back to English (en) and Spanish (es), respectively.
Note that I also plan on bringing up the issue to the CLDR Technical Committee that es-XX, where XX is any country within Latin America (419) should fall back to es-419 even if es-XX is not a valid locale. This would, however, require a new structure added to the LDML spec unless a locale was created for each combination of es with each remaining country within 419.
Thought I might be able to do this for you, but I had a couple of questions.
Did you have any specific text that you had put together for this yet?
Is there a list of supported locale values that a user can reference? (short of grep'ing CLDR/Number/Data/Base.pm)
I found a nice reference to picking the right locale that I thought might be helpful (http://cldr.unicode.org/index/cldr-spec/picking-the-right-language-code) but it doesn't give any indication that a specific Language/Region pair would be invalid as long as both codes are recognized separately; even if the combination seems to make no sense. Any thoughts on providing guidance to achieve a valid locale entry?
Users occasionally report that the wrong formatting is used for several non-existant locales including Mexican English (
en-MX
) and Brazilian Spanish (es-BR
). We should document that since these locales don’t exist, they would fall back to English (en
) and Spanish (es
), respectively.Note that I also plan on bringing up the issue to the CLDR Technical Committee that
es-XX
, whereXX
is any country within Latin America (419
) should fall back toes-419
even ifes-XX
is not a valid locale. This would, however, require a new structure added to the LDML spec unless a locale was created for each combination ofes
with each remaining country within419
.