Re: Last Call feedback on Date/Time controls

On Tue, Jun 28, 2011 at 9:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> This shouldn't be the author's problem, in my opinion.  Localization
> of strings in form controls should be based on the UA's language, so
> that everything is consistent.  There's no reason for every author to
> re-solve this problem when it can be solved once per UA.

I strongly disagree.  Things that are visually part of the page need
to be visually in the language of the page.  Browsing an
English-language website and suddenly having a word thrown in (say)
Hebrew just looks bizarre, and that's even if it's only one word --
let alone a whole date-picker.

Having browsers use the language of the page to display the control is
better, but still not great.  There are *tons* of languages out there
that have a nontrivial number of online speakers.  There are 208
Wikipedias that have at least 1,000 articles, and 103 with at least
10,000:

http://meta.wikimedia.org/wiki/List_of_Wikipedias

You have to account for the fact that some of these had stub articles
mass-created by robots, but still -- browsers are not going to support
as many languages as authors, ever.


However, I definitely think that initial implementations should just
try to get a good basic implementation working.  That's a lot of work
already.  Once there's something to use, authors will be able to try
it out and give specific feedback on what omissions are the biggest
problems for them, together with providing detailed use-cases.
There's lots of prior work on customizable date controls, but the web
has different needs from typical applications, and it would be best if
we could get real-world web-specific use-cases before deciding how to
expand the API.

On Tue, Jun 28, 2011 at 11:20 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> If this indeed is for the display-current-value state. I kind'a like
> some old microsoft Visual Basic APIs that I used in a previous life
> which let you describe a format using a string like "yyyy MM dd".
> Though obviously this had quite a few limitations, but somehow always
> seemed to work out for me (but swedish date formatting rules aren't
> particularly complicated).
>
> However I wouldn't be surprised if it has severe limitations that
> makes it not work well for many locales. I would suspect microsoft has
> a lot of experience with this type of solution. If that experience
> simply is "it doesn't work well enough in practice" then we'd of
> course have to find another solution.

PHP has a pretty comprehensive function like this, although English-only:

http://us.php.net/manual/en/function.date.php

MediaWiki has a variant that can be used in wikitext and is internationalized:

http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time

Notable additions compared to the PHP function include the ability to
output month names in genitive, for languages where that's needed
(apparently including Polish); Iranian, Hebrew, and Thai solar
calendar support; and some formatting controls, like to use Roman
numerals.

I think something like this could work okay in practice, provided the
resulting string isn't exposed to script.  If it were exposed to
script, we'd have to have interop on the localizations, which would be
infeasible.  But I doubt this is the best approach in the end.

> One solution to this would be to use the lang attribute on the <input>
> (or an ancestor of it) to allow the website to choose which language
> to use for the strings. This would of course require UAs to have the
> names of the months and weekdays localized into terribly many
> languages. I don't know if this is realistic or not, but given the
> small number of strings that needs to be localized, it might work. Or
> at least it might work well enough to cover 80% of the use cases.

If all you need is things like months and weekdays, you could always
use data from an existing project with no effort.  Running grep
"^'sunday'" Messages*.php | wc -l in MediaWiki's languages/messages/
directory says that we have localizations of that string into 293
languages, from Abkhazian to Zulu.  I just asked a couple of our l10n
people, and I'm told that the messages are all CC-BY 3.0, so anyone
can use them.  There's no guarantee as to the quality, but you'd think
strings like "Sunday" are pretty easy to translate correctly.

(These translations come from translatewiki.net, by the way.  It turns
out wikis are *amazingly* good at getting comprehensive translations
into obscure languages, as long as you don't insist the obscurer
languages have to have top-notch translations.  I don't know why more
open-source projects haven't adopted the approach.)

> A pretty terrible fallback would be to introduce attributes which let
> the site define the strings to use for the month and weekday names.

This would be especially terrible because the site has no way of
knowing how it will be formatted.  One browser might have narrow date
columns with headers "S", "M", . . . , "S" so (for instance) the right
Hebrew translation would be ‏"א", "ב", . . . , "ש"‏.  Another might
have wider date columns that say "Sunday", "Monday", . . . ,
"Saturday", so the correct Hebrew translation might be ‏"יום א'", "יום
ב'", . . . , "שבת"‏.  A distinction like that might not even make
sense for a language like Chinese, where the full day name is a single
character, so if the UI were designed for wide columns it would just
look silly.  And of course in the Hebrew example, you'd need it to be
RTL, so it's not just string substitution.

So I remain firmly convinced we shouldn't add any new API until we
have the existing stuff down.  I think in the end, to give authors
full flexibility, it might be necessary to let them totally replace
the rendering, so they're just getting the API part for free and not
the display.  But that's a concern for the future.

Received on Thursday, 30 June 2011 20:10:29 UTC