On 4/3/2012 1:49 PM, Elsebeth Flarup wrote:
>If the visible display of the value of the Last-Modified header
(which may or may not reflect the actual last modification time) is
regarded as useful, it should of course be in the same language as the
rest of the page.
I completely disagree. There may be many applications and web pages
that are not translated into my preferred language, but I still want
to be able to use my regional preferences. Especially common for US
English apps and sites - I am entirely happy to use the English
language UI, but I am very unhappy if I cannot see sensible dates with
a dd/mm/yyyy order, a calendar where Monday is the first day of the
week, and numbers where the decimal separator is a comma, just to
mention the most common issues.
For dates, there are two things affected by the locale. One is the
language of the names of day and month. The other is the regional
preference for their arrangement (date order).
I can certainly sympathize with the view that the effect of these on the
user (foreign or non-native user, to be more precise) is different.
Switching between two different arrangement (especially short date
formats) can indeed be more confusing than switching languages. However,
for long data formats, getting the day month names in other
scripts/languages than rest of the page is irritating in another way -
and users do complain about it.
Given all this, I still don't think it makes sense to alternate the
format randomly based purely on whether the date is generated on the fly
or during page edit.
The latter is the situation for the Unicode site. Many pages have a date
(see all the reports) in the header, which is static and formatted
according the document locale (to use that term). The "last updated"
date happens to be generated at runtime, because that is a convenient
way to do it, but there's nothing intrinsic that requires it to be
dynamic. (One might imagine some hypothetical alternative editorial
process that would create a static time stamp at file upload).
Therefore, overall consistency would suggest that exposing the dynamic
nature of this particular string to the user by localizing it
differently is a bug or poor design) and not a feature. Worse, on pages
that have both a static and a dynamic date, using different formatting
rules could create confusion. (The worst case scenario would happen if
they were both in short date format).
On the other hand, I can see situations where it might make sense to
localize date formats even for an untranslated site. Those situations
revolve typically around user input, but they don't apply here.
A./
