5 ms·

What is the reasoning behind the decision to not make localization configurable? Can we agree that some webpages and webapps have already make the decision to

What is the reasoning behind the decision to not make localization configurable? Can we agree that some webpages and webapps have already make the decision to control the locale through the app and not choose the environment default? My OS and browser locale is pt-BR, but if for whatever reason I am not happy with a pt-BR UX, which is often, I want to be able to change it on a case by case basis. For example, any documentation I look up, like say on MDN or AWS, I want to see it in english and not a poor/incomplete translation. If I play a Star Wars game on my browser or phone I do not want any translations, I want the original terms like scoundrel instead of the translator's choice of terms. It is already bad enough as it is for the reasons I pointed out, now we are gonna have that same nightmare in forms as well? Sure webapps that actually care will find a non standard way, as they already do, but then we are not actually improving when in 2017 you have to load 3rd party libs just to be able to choose the locale of a date input. <input type=date> (environment default) <input type=date locale="pt-BR"> (actual chosen locale) Is that too much to ask?

jhasse 9y ago
I wouldn't want websites to overwrite my locale setting like that.
- jeltz 9y ago
  But they already do it for dates in the content of the pages (there is no API for a web server or JS to get the browser UI locale). Why should form elements be different? Imagine how confusing a web site with a D/M/Y dates and a browser with M/D/Y forms would be.
  - jhasse 9y ago
    > (there is no API for a web server or JS to get the browser UI locale) There is: new Date().toLocaleDateString()
- Hussell 9y ago
  I want the content, number formats, date formats, map labels, etc. on my website to all use the same locale. Date input widgets are no exception. I can't afford to give full support to all locales (translation costs are ridiculous), so detecting and supporting the user's locale seems to be pointless unless they happen to be using one of the limited set I can give full support to (en-CA and fr-CA in my case). It seems like a far better idea to allow the user of my website to choose one of the supported locales, and see everything in the same consistent format than to have a few input widgets on each page decide to configure themselves based on the locale the browser was compiled with. Edit: also, consider testing. Am I supposed to download a bunch of variants of Firefox to test my locale support?
  - jhasse 9y ago
    > I can't afford to give full support to all locales (translation costs are ridiculous) Even if your page isn't translated I would still want the dates to be localized. I understand English, but not the US time and date formatting.
    - Hussell 9y ago
      That's a problem we already deal with by having labels for the date inputs which explain the expected format. This is especially necessary in Canada, where until recently there was no recommended format, and the government recommendation isn't even well known yet much less universally used. So, depending on what part of the country you live in, you'll expect a different date format, even though you're technically using the same locale. So, to do what you want, I'd have to make different versions of all the supporting documentation for each possible date format, and then get each version translated. Also, displaying the dates the user just entered in a different format is a usability problem. (Users will complain. A lot.) So, if I did what you want, I'd likely be asked to display all dates, everywhere on the site, in the format the browser happened to be compiled with. This is possible for dates in the database, but not so much for dates in static content like news releases. Just to be clear: I have no objection to making it easy for a website to have date input widgets which use the user's locale. I just want it to be equally easy for a website to have date input widgets in a specific locale. For example, how am I to make a website comparing date input widgets for different locales?
nonsince 9y ago
Ideally there would be a better way to choose locale on a per-site basis rather than having it be baked into each app individually. Many apps have no settings page, and those that do often require you to log in to change the settings. I have my browser language set to Dutch but every time I touch Wikipedia or MDN I have to append "english" to my search terms to get a version of the article that isn't strictly inferior.
c-smile 9y ago
According to HTML5 specification this: <input type=date lang="pt-BR"> shall work. Like here: https://sciter.com/temp/date.png https://sciter.com/temp/date.png
482794793792894 9y ago
The reasoning is that this is a brand-new feature that just landed in the Alpha release of the browser and they're just not done yet with every secondary implementation aspect. Manishearth, who's a Mozilla dev, commented in another thread that he's currently looking into making it configurable.

jhasse 9y ago

I wouldn't want websites to overwrite my locale setting like that.

jeltz 9y ago
But they already do it for dates in the content of the pages (there is no API for a web server or JS to get the browser UI locale). Why should form elements be different? Imagine how confusing a web site with a D/M/Y dates and a browser with M/D/Y forms would be.
- jhasse 9y ago
  > (there is no API for a web server or JS to get the browser UI locale) There is: new Date().toLocaleDateString()
Hussell 9y ago
I want the content, number formats, date formats, map labels, etc. on my website to all use the same locale. Date input widgets are no exception. I can't afford to give full support to all locales (translation costs are ridiculous), so detecting and supporting the user's locale seems to be pointless unless they happen to be using one of the limited set I can give full support to (en-CA and fr-CA in my case). It seems like a far better idea to allow the user of my website to choose one of the supported locales, and see everything in the same consistent format than to have a few input widgets on each page decide to configure themselves based on the locale the browser was compiled with. Edit: also, consider testing. Am I supposed to download a bunch of variants of Firefox to test my locale support?
- jhasse 9y ago
  > I can't afford to give full support to all locales (translation costs are ridiculous) Even if your page isn't translated I would still want the dates to be localized. I understand English, but not the US time and date formatting.
  - Hussell 9y ago
    That's a problem we already deal with by having labels for the date inputs which explain the expected format. This is especially necessary in Canada, where until recently there was no recommended format, and the government recommendation isn't even well known yet much less universally used. So, depending on what part of the country you live in, you'll expect a different date format, even though you're technically using the same locale. So, to do what you want, I'd have to make different versions of all the supporting documentation for each possible date format, and then get each version translated. Also, displaying the dates the user just entered in a different format is a usability problem. (Users will complain. A lot.) So, if I did what you want, I'd likely be asked to display all dates, everywhere on the site, in the format the browser happened to be compiled with. This is possible for dates in the database, but not so much for dates in static content like news releases. Just to be clear: I have no objection to making it easy for a website to have date input widgets which use the user's locale. I just want it to be equally easy for a website to have date input widgets in a specific locale. For example, how am I to make a website comparing date input widgets for different locales?

nonsince 9y ago

Ideally there would be a better way to choose locale on a per-site basis rather than having it be baked into each app individually. Many apps have no settings page, and those that do often require you to log in to change the settings. I have my browser language set to Dutch but every time I touch Wikipedia or MDN I have to append "english" to my search terms to get a version of the article that isn't strictly inferior.

c-smile 9y ago

According to HTML5 specification this: <input type=date lang="pt-BR"> shall work. Like here: https://sciter.com/temp/date.png https://sciter.com/temp/date.png

482794793792894 9y ago

The reasoning is that this is a brand-new feature that just landed in the Alpha release of the browser and they're just not done yet with every secondary implementation aspect. Manishearth, who's a Mozilla dev, commented in another thread that he's currently looking into making it configurable.