<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.3">
</HEAD>
<BODY>
On Tue, 2010-08-31 at 15:40 -0400, Aryeh Gregor wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke <<A HREF="mailto:whatwg.org@kaor.in">whatwg.org@kaor.in</A>> wrote:
> Besides, <time>2010</time> in a British news article would allow users e.g.
> in Japan to have these dates displayed as 平22年. That's clearly an advantage
> over the number 2010 alone.
I would say the opposite. If they can read the English news article,
they'll necessarily know what "2010" means. But they might not be
able to read Japanese. Maybe they're borrowing a Japanese person's
computer, for example, or maybe the browser's idea of the user
language is otherwise wrong.
Also, content that behaves differently based on the browser settings
of the viewer is confusing and can cause hard-to-debug problems.
Users will think that the author of that British article actually
wrote out a Japanese date, and be completely at a loss to explain why.
Even if they can actually understand the date, the incongruity will
look like a bug.
It could be outright misleading if there are two year display formats
that look the same but actually have different meaning. A plain year
number in Arabic numerals like 2010 could refer to any number of
totally different year-numbering conventions, and the only way to tell
them apart currently is the page's context. Having the browser change
the number to some convention that doesn't match its surroundings
makes it impossible to guess the convention.
And finally, it just looks weird. I would find it extremely strange
to have all dates on pages I'm reading replaced with Hebrew dates,
even though I understand those just fine. I wouldn't want that at
all, and I find it hard to believe that many actual users do in real
life.
Basically, any kind of attempt to have browsers localize dates that
are actually displayed in content is a terrible idea, and the spec
should remove all mention of any such thing. I'm pretty sure I've
said all this before, though.
</PRE>
</BLOCKQUOTE>
<BR>
I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be.<BR>
<BR>
Localisation in this case would mean that I could read the document and easily figure out what the date was.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
Thanks,<BR>
Ash<BR>
<A HREF="http://www.ashleysheridan.co.uk">http://www.ashleysheridan.co.uk</A><BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>