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