While countries such as Switzerland use a specific format for numbers common to all languages in that country, rather than the format of the country where the base language is from.ĭon’t be afraid to use a different locale instead of the one you need, if it is not supported, and the base language doesn’t give the correct formatting. This is a problem in English for dates, as the US uses an almost unique date format. In these cases the browser will likely fall back to the base language. While there are not too many major languages that are missing, Chrome does not support many regional variations, outside of British and American English Portuguese and Brazilian Portuguese and multiple Spanish variations. You can check the CLDR data (or by type), but browser implementations don’t always agree. Find languages that use the same customs as the language that isn’t supported.įor example, no (Norwegian macrolanguage) is not supported by Chrome or Firefox, but you can give a fallback of Norwegian Bokmål, Norwegian Nynork, and if all else fails, Danish (which uses the same sort order) if you want to collate according to Norwegian customs: new Intl.Collator() īe careful though just because a locale behaves the same as another for one type of data, doesn’t mean it does for all. If you need to use a language that is not supported by a browser, you can use a fallback by providing an array. Not all languages and regions are supported by all browsers, but it is possible to supply a list of locales, or fix up flaky support. The API also gives you much more control over formatting and collation options, such as varying the strictness of matching strings, setting minimum significant digits, displaying the month in its long, short or narrow form, and so on. While the raison d’être of a internationalisation API is for supporting multiple locales, do not dismiss it if you are writing a monolingual app.įor one, you can use methods such as toLocaleString using the language of the page in question, rather than that of the browser, which is the default when no locale is specified. Use the API even for monolingual apps and sites You’ll also probably want to listen for changes to the attribute value if you have an app where the language can be changed. You may want to check for a language tag set in an lang attribute closer to where you will be inserting the result if you have a multi-lingual document. This assumes you are formatting something in the same language as the actual document. This takes the language tag from the HTML lang attribute if it exists, otherwise takes it from the xml:lang attribute, and if all else fails, use a fallback language. Set the locale based on the document language Lang = root.lang || root.getAttributeNS("", "lang") || "en", One approach would be to set the lang attribute (or xml:lang for XML documents, such as SVG), and then use this to set the locale. Outside of small demos, it would be best not to hardcode the locale. In the previous blog post, I mostly set the locale by assigning it to a variable at the top of the JS file. Setting the locale based on the document language In this follow up I will show some tips and tricks for using the API and working around issues I found will writing that post. In my previous post, I introduced the Internationalization API.
0 Comments
Leave a Reply. |