1

Similar to A good solution how to localize and let user choose language on HTML page

but I am specifically wondering about localization of control elements such as required on input or date fields.

I would like to follow https://www.w3.org/International/questions/qa-lang-priorities and I already set <html lang="..."> to the appropriate language.

However, I don't think the popular browsers support that attribute correctly in that it will always use the OS locale to display the date field or the required error messages.

So my conclusion at the moment is to develop custom components for the controls so that they recognize the html lang attribute (which kind of defeats the purpose of using standard HTML controls)

2
  • 1
    Not sure if it's an answer, but my standard example for not relying on the browser's locale is, for example, someone from the UK arm of a multinational company visiting the company's offices in France and using a PC there. Yes, they could change the browser's locale, but would need to remember to change it back. Being able to change the locale within the app/page avoids this. (And, if the app was set up to store a user's preference, they may not even need to change anything: seeing "TripeHound" logging in would automatically select English, even in a French-configured browser).
    – TripeHound
    Jun 15 '20 at 12:56
  • @TripeHound its an answer just add how you would handle it with the typical standard controls. Jun 15 '20 at 13:03
1

On your titular question: Should I override controls so that it handle different locale's or let the browser handle it?, my "go to reason" for not relying on a browser's locale is the situation where someone from the UK arm of a multinational company is visiting the company's offices in France and using a PC there.

If the web application is relying on the browser's settings (which more than likely will be set to "French") then the person from the UK has to change those settings, and – if they are being considerate to their hosts – may need to change them back.

On the other hand, if the web application has its own way of changing language/locale, then not only will the UK user probably not have to worry about resetting things, they may also never need to change the setting in the first place:

  • If the app never saves the choice (beyond the current session), there's nothing to reset (but anyone wanting to change the locale will have to do so every time).

(Assuming users log into the PC with their own username: very likely in a corporate environment):

  • If the app saves the choice in a cookie, then the first time someone new uses a given PC, they won't have a cookie and will need to select the locale. Thereafter, when using the same PC they will see their preferred language. Other users (with their own cookies) will not be affected.

  • If the app remembers the user's choice within the app itself, then when "TripeHound" logs in, not only will my choices not affect anyone else, the chances are the app will already know I prefer English and I won't need to change anything.

(Only if the app stores the choice in a cookie, and everyone logs into PCs with a generic account would the setting need to be reset. This is an unlikely scenario in a modern business setting. I hope! Nowadays, even in a non-business setting it is common for different people sharing a PC to have their own accounts.)


As to the question at the bottom of the question body: should you (continue to?) use custom components to support browsers that don't fully respect the lang= attribute? First I'd note that that seems to be more of a "How do I implement..." question (compared with a "How should I design..." question that SE:UX prefers), nevertheless...

Any answer would depend on how important you feel it is for dates/required elements to be fully localized, and how far off you "guestimate" full compliance by popular browsers might be:

  • If it's very important to fully localize, and some mainstream browsers currently don't comply, customized controls is probably the answer. (They won't stop working even if browsers catch up).

  • If full localization is not vital, but more desirable than nice to have, and you've already got customized components (or can lay your hands on suitable implementations of them), then you may as well use them now, at least until browsers catch-up.

  • If full localization is only nice to have, but browsers seem to be moving in the right direction, you might decide that standard controls are "good enough" for the time being, and will be "perfect" when browsers do catch-up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.