58

I know that at the time of this writing only Opera supports a browser UI for

<input type="date" name="mydate">

and maybe my attempts to localize this field have been met with frustration because niceties like localization have not yet been included in their implementation, but I don't even see mention of it in the HTML5 spec. Is there a way that localization should be specified? Should I do lang="fr" on a parent element?

Some notes on the implementation of the site in question:

  • Localization (language) is explicitly picked by the user because they are managing data in multiple languages and it is not reasonable to expect that the user's browser chrome is in the language being viewed or that the browser is providing desired language request headers.
  • I want to be sure that if the page is rendered in French that the date picker provided by browser chrome shows options that make sense for French language.
  • The plan is to fall back to jQueryUI for browsers that do not support type="date", I will use the detection mechanism provided in Dive into HTML 5
µBio
  • 10,668
  • 6
  • 38
  • 56
lambacck
  • 9,768
  • 3
  • 34
  • 46

3 Answers3

21

From what i know, the thinking behind what we do in Opera (full disclosure: I work for them) is that the date picker is almost an extension of the chrome, a browser-native control. As such, it will be localised according to the language of the browser, rather than the language of the page being viewed.

  • 6
    3 problems with that: 1. It is jarring as a user to have to switch languages (chrome vs content) for a date picker. 2. The data will be rendered to the page in a locale, will the chrome (in English mode) understand the French and that Juin means June? 3. Server side will expect data formatted in a locale and parse accordingly, if the date picker does format the date for the expected locale, the server will misinterpret it. These problems are not limited to dates. What about numbers? French uses a comma instead of a decimal. How will the chrome handle that? The approach seems short sighted. – lambacck Jun 04 '10 at 17:19
  • 7
    1 it acts like, say, the file type input in all browsers...that also localises according to the browser locale, not the page. i can see arguments for and against this. 2 don't quite get what you mean here-assuming this relates to 3 regardless of how the UI for the datepicker is displayed, the end result (which is then passed to the server) is always in the same ISO format, regardless of the language shown by the UI. not tried the numbers thing (assuming you mean input type="number")...but here i can see that it would indeed have potential issues. don't know if that's localised currently, tho. – Patrick H. Lauke Jun 06 '10 at 00:56
  • 1
    I don't think that ISO format is reasonable response for progressive enhancement. If the browser falls back to a plain input box and they don't have Javascript enabled (yes those people exist) they will then have to enter the date in ISO format? If the user is non-technical, it is unlikely that they will want to enter the date in ISO format (even know how). – lambacck Oct 05 '10 at 16:33
  • According to [current whatwg spec](http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#language), the language of a node is determined recursively looking up the lang attribute. I don't think many browsers support this yet. – Jens Feb 04 '13 at 05:58
  • 1
    Even now, close to a decade later, every major browser still seems to do it this way. And it is still WRONG. The date input is a part of the document / page and SHOULD follow the locale given by the `lang` attribute of an enclosing element. – Rasmus Kaj May 14 '20 at 11:11
  • The language of a software is not the same as a locale. I run all my software in English, except for apps developed for the local market, here I want the software to be in the native language, be it Swedish or Japanese, but the locale for how I want date, time and numbers formatted, has NOTHING to do with the language, or timezone. – NiKiZe Apr 24 '22 at 14:24
16

I agree with lambacck. Currently I am writing Javascript code to make the new form features available cross browser, using jQuery UI for this.

I work in Luxemburg which is a good place to illustrate the localization problem in more detail.

Most websites we write are multilingual de|fr|en. From our stats we can tell, that people use the language switch on the site to display their preferred language, but this choice rarely matches the preferred browser locale.

If the locale of the calendar etc. field is done by the OS, this brings us back to the unfortunate <input type=file> situation where the label reads Upload a file and the button says Parcourir. You can do nothing about this language mix and I always found this to be a major annoyance.

Conclusion, I have to overwrite the default calendar with the jQuery one to be sure it does what I want.

In my opinion a configurable API or at least a way to manipulate the locale on a HTML level would be great. Since the new field types are not widely adopted yet by the other browser manufacturers, I imagine this issue could still be taken in account.

Thanks for reading this.

Dieter Raber
  • 1
  • 1
  • 2
  • "where the label reads Upload a file and the button says Parcourir": That just means, your application doesn't respect the users browser language… – feeela Mar 10 '11 at 16:33
  • 11
    @feeela: What if your website has a language-picker to let the user override the default (browser-provided) language... – fretje May 14 '11 at 20:23
  • 3
    The users are (perhaps unfortunatley) explicitly asking for pages in a different locale than the browser / desktop setting. I live in Sweden, and here it seems everyone (except me) keeps their desktop running in English, but everyone (including me) wants the content in Swedish when possible. – Rasmus Kaj May 14 '20 at 11:16
  • This happens in Indonesia too (and most south east asia). Most people have english localization for OS and browsers, but they really want to see page content in their local language. This is really an oversight by browser makers. Their date input and file input should respect the language defnied in , not the OS language. – Daniel Wu Jan 18 '21 at 02:10
4

For mobile the best solution we have found is to use a text input for date entry, with a calendar icon next to it that has an invisible date input over the icon.

Advantages:

  • works on all browsers and devices
  • can use next button into date on iOS (if multiple fields)
  • user can type in date (very useful)
  • avoids iOS UI bugs (1. editing existing data with blank date, next into date, date value is set to today - arrrgh, 2. keyboard showing, next into date, popup shows and keyboard disappears - ouch)
  • use a date library to show date in input as localisation set for your user's account (not browser), and can use a smart date library (type in "tomorrow" etc).
  • click calendar icon to see date as browser localisation
  • graceful fallback even if input type=date not supported by device/browser (e.g. some Android devices don't support date or have serious bugs).
  • for desktop (detected by no touch support) we show our own custom date dropdown.

HTML is a something like:

<input type=text>
<span style=position:relative>
  <input type=date class=date-input tabIndex=-1>
  <div class=date-input-icon>&#x25BC;</div>
</span>

CSS:

.date-input {
  position: relative;
  z-index: 1;
  webkit-appearance: none;
  display: inline-block;
  opacity: 0;
  width: 1em;
}

.date-input-icon {
  position: absolute;
  right: 0;
  width: 1em;
}
robocat
  • 5,293
  • 48
  • 65
  • 4
    The question is about localization not other issues related to use the native type=date widgets. No mention of localization is made in the answer. – lambacck Mar 26 '15 at 02:06
  • Never mind, I see the localization part which is use javascript (which is what the accepted solution already is). – lambacck Mar 26 '15 at 02:07
  • What is the advantage of having a hidden date input rather than just using type=text when the button provides selection UI. – lambacck Mar 27 '15 at 14:09
  • @lambacck. JavaScript is useful to synchronise the two inputs, although it will gracefully fail if JavaScript is disabled. The localisation code can run on server, and use Ajax to synchronise the two inputs. The main advantage is that browser support for the date input is patchy, and localisation is crappy, but having the native date picker is really nice for users when it is available. Just saying that this solution had worked really well for us on mobile, YMMV. – robocat Mar 28 '15 at 21:23