2.1. Syntax A language tag is composed from a sequence of one or more “subtags”, each of which refines or narrows the range of language identified by the overall tag.
Seems like Xojo is limited to <language>-<region>
Appendix A.
Examples of Language Tags (Informative)
Simple language subtag:
de (German)
fr (French)
ja (Japanese)
Note:
also fails on Desktop apps.
It should work with “en” and other languages that just report 2 letters.
The reason Xojo uses <language>-<region> has more to do with localized constants and what the desktop operating systems require than anything else. That was around long before the web framework or the Locale class.
“en” by itself can’t work. If you just look at the differences between en-US and en-GB you’ll understand why. For example…
Dates: United States uses m/d/yyyy, Great Britain uses d/m/yyyy
Currency: US uses $, GB uses £
So you must use the region when getting a Locale. This is not a bug.
We also spell things differently. Colour vs Color for example. I know that doesn’t change the locale but it does point out that ‘en’ isn’t qualified enough.
That’s a good point though. You may find that in the long form dates things are spelled differently too.
IIRC we had to jump through some hoops to get the WebDatePicker control to localize for this very reason. There are some languages that could work because there was only one region and others that could not.
At least the bug is that Xojo is using links to official documents that mention the use of only Language and not region as valid and Xojo can’t do that. There is no warning that will not work.
If that’s the case then it’s still not a Xojo bug. You would need to look at the library that they’re using for locale and tell them about your problem. I believe it’s libicu.
so it looks like en and eo can be used, because there is no information on that link that a region is needed.
Besides that if I use this code:
Var MyLocale as New Locale("en-MX")
what should I expect as ‘en-MX’ is not on the list?
For me, reading the documentation and following the links and see the tables, I expect to get a RuntimeException. No?
Edit: I know Xojo will not change this (it is as designed), maybe they can add a note on the documentation at least?
There’s a simple solution to this in a web app. You could do something like this:
Dim languageCode as string = session.languageCode
Dim languages as String = Session.Header("Accept-Language")
Dim rx as new RegEx
Rx.searchpattern = "([a-z]+-[A-Z]+)"
Dim rm as new regexmatch = rx.search(languages)
If rm <> nil then
LanguageCode = rm.subexpressionstring(1)
End if
Now what I don’t know is whether this will muck with xojos dynamic constant stuff, so it might be better to be exposed as a computed property on Session that you only look up once.
While I haven’t included it, the q values in that string are a “quality” of the guess. So in your case, the browser is saying 90% sure that the user wants English and then German, 80% for en-GB and then 70% for en-US, 60% nl (Dutch/Flemish).
Thanks for al the suggestions and insights. It is now clear why the two letter language code will not work without a region code.
I do find however that the documentation should be clear about this, directly stating that you need to have a region code with the language code; also removing incorrect information that suggests you can use the Session.LanguageCode directly to construct a new Locale.
