1 23019157 2020-08-03 op I'll surely not be the first one to acknowledge that localization is
2 23019157 2020-08-03 op way more complex than a mere translation, but recently I was almost
3 23019157 2020-08-03 op bitten by a details, and that's the reason for this entry. There are
4 23019157 2020-08-03 op cases when it's easy to think that localization equals translation.
6 23019157 2020-08-03 op One common thing is printing dates: the date of when a comment was
7 23019157 2020-08-03 op posted, the publication date of a post or the creation date of an
8 23019157 2020-08-03 op entity, and so on. The javascript `Date` object has an
9 23019157 2020-08-03 op `.toLocaleDateString()` method that prints a locale-aware
10 23019157 2020-08-03 op representation of the date using the user locale, or the provided one
12 23019157 2020-08-03 op d = new Date()
13 23019157 2020-08-03 op d.toLocaleDateString() // my locale is en-US
16 23019157 2020-08-03 op d.toLocaleDateString('it-IT')
19 23019157 2020-08-03 op d.toLocaleDateString('ja')
22 23019157 2020-08-03 op Now, let's say that you have an application that's available in
23 23019157 2020-08-03 op various languages. Let's assume, without loss of generality, that
24 23019157 2020-08-03 op Italian isn't among the languages you support, what happens if an
25 23019157 2020-08-03 op Italian use you web application? You may, as it's common, use English
26 23019157 2020-08-03 op as default fallback language, and the user is probably fine with that.
28 23019157 2020-08-03 op If you've used `.toLocaleDateString`, or similar functions, without
29 23019157 2020-08-03 op specifying the locale, now you're screwed. Or, to say at least, you
30 23019157 2020-08-03 op have a confused user. Your user will read phrases like:
32 23019157 2020-08-03 op > [...] posted on 3/8/2020.
34 23019157 2020-08-03 op that just can't be interpreted correctly. The user will probably
35 23019157 2020-08-03 op assume that since the site is in English the date is probably in the
36 057f7547 2020-08-03 op format `month/day/year`, while it may be according to his locale and
37 23019157 2020-08-03 op thus be interpreted as `day/month/year`.
39 23019157 2020-08-03 op The fundamental problem here is a lack of context between the
40 23019157 2020-08-03 op application and the user. While the HTML `time` tag has the
41 23019157 2020-08-03 op `datetime` attribute to provide a machine-readable date, no browsers
42 23019157 2020-08-03 op as far as I know provide a way to inform the user how that date (or
43 23019157 2020-08-03 op date time) should be interpreted. It's only useful to machines, not
46 23019157 2020-08-03 op To reach a conclusion, what should be done? Honestly I don't think
47 23019157 2020-08-03 op there is a silver bullet. In some occasions I decided to use the less
48 23019157 2020-08-03 op ambiguous `YYYY/MM/DD` format, but it may not always be applicable.
49 23019157 2020-08-03 op You could try to map languages with locales, but it also may not work
50 23019157 2020-08-03 op as there isn't a bijection between languages and locales
52 23019157 2020-08-03 op d.toLocaleDateString('ja')
54 23019157 2020-08-03 op d.toLocaleDateString('ja-JP-u-ca-japanese')
57 23019157 2020-08-03 op and bloating the settings with things like "How you prefer date to be
58 23019157 2020-08-03 op printed" may be a bit silly.
60 23019157 2020-08-03 op I'm starting to think that providing locale-aware APIs that don't take
61 23019157 2020-08-03 op an explicit locale as **required** argument is just broken, but I may
64 23019157 2020-08-03 op P.S. node, at least on my system -- OpenBSD -CURRENT as of a couple
65 23019157 2020-08-03 op of days ago, seems to completely ignore the given locale.
67 23019157 2020-08-03 op P.P.S. [this commit][commit] from mpv was just too funny to read, it
68 23019157 2020-08-03 op reinforces my thought on requiring the locale in locale-aware APIs.
70 23019157 2020-08-03 op [commit]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe
