commit 23019157ada99de6cad65e5c82639012bfc244ae
from: Omar Polo <op@omarpolo.com>
date: Mon Aug 03 11:00:35 2020 UTC

new post: localization of dates in web pages

commit - 4e33b4c799eb4ab191c0cf155fd62a9f77f74961
commit + 23019157ada99de6cad65e5c82639012bfc244ae
blob - /dev/null
blob + 647863be80f16310db6944846c86215d22fd5cca (mode 644)
--- /dev/null
+++ resources/posts/localization-of-dates-in-web-pages.md
@@ -0,0 +1,70 @@
+I'll surely not be the first one to acknowledge that localization is
+way more complex than a mere translation, but recently I was almost
+bitten by a details, and that's the reason for this entry.  There are
+cases when it's easy to think that localization equals translation.
+
+One common thing is printing dates: the date of when a comment was
+posted, the publication date of a post or the creation date of an
+entity, and so on.  The javascript `Date` object has an
+`.toLocaleDateString()` method that prints a locale-aware
+representation of the date using the user locale, or the provided one
+
+	d = new Date()
+	d.toLocaleDateString() // my locale is en-US
+	// 8/3/2020
+
+	d.toLocaleDateString('it-IT')
+	// 3/8/2020
+
+	d.toLocaleDateString('ja')
+	// 2020/8/3
+
+Now, let's say that you have an application that's available in
+various languages.  Let's assume, without loss of generality, that
+Italian isn't among the languages you support, what happens if an
+Italian use you web application?  You may, as it's common, use English
+as default fallback language, and the user is probably fine with that.
+
+If you've used `.toLocaleDateString`, or similar functions, without
+specifying the locale, now you're screwed.  Or, to say at least, you
+have a confused user.  Your user will read phrases like:
+
+> [...] posted on 3/8/2020.
+
+that just can't be interpreted correctly.  The user will probably
+assume that since the site is in English the date is probably in the
+format `month/day/year`, while it may be according to its locale and
+thus be interpreted as `day/month/year`.
+
+The fundamental problem here is a lack of context between the
+application and the user.  While the HTML `time` tag has the
+`datetime` attribute to provide a machine-readable date, no browsers
+as far as I know provide a way to inform the user how that date (or
+date time) should be interpreted.  It's only useful to machines, not
+to users.
+
+To reach a conclusion, what should be done?  Honestly I don't think
+there is a silver bullet.  In some occasions I decided to use the less
+ambiguous `YYYY/MM/DD` format, but it may not always be applicable.
+You could try to map languages with locales, but it also may not work
+as there isn't a bijection between languages and locales
+
+	d.toLocaleDateString('ja')
+	// "2020/8/3"
+	d.toLocaleDateString('ja-JP-u-ca-japanese')
+	// "R2/8/3"
+
+and bloating the settings with things like "How you prefer date to be
+printed" may be a bit silly.
+
+I'm starting to think that providing locale-aware APIs that don't take
+an explicit locale as **required** argument is just broken, but I may
+be wrong.
+
+P.S. node, at least on my system -- OpenBSD -CURRENT as of a couple
+of days ago, seems to completely ignore the given locale.
+
+P.P.S. [this commit][commit] from mpv was just too funny to read, it
+reinforces my thought on requiring the locale in locale-aware APIs.
+
+[commit]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe
blob - d505f771870d8ee2852d6d1cc57cc65315993c0c
blob + 4b9b36acc50b780f164b91c70fcc5c418c9f92f5
--- resources/posts.edn
+++ resources/posts.edn
@@ -1,4 +1,12 @@
-[{:title "enjoying CDPATH"
+[{:title "Localization of dates in web pages"
+  :slug  "localization-of-dates-in-web-pages"
+  :date  "2020/08/03"
+  :tags  #{:l10n}
+  :short ""
+  :music {:title "Dream in Color"
+          :by    "Grant Lee Buffalo"
+          :url   "https://www.youtube.com/watch?v=uqyduBWlmKs"}}
+ {:title "enjoying CDPATH"
   :slug  "enjoying-cdpath"
   :date "2020/06/27"
   :tags  #{:sh}