Re: [widgets] P&C, outstanding feedbac...

I wrote:
> hey, you won't like this, but... I think we botched the
> l10n stuff :). The problem is that the design is based on individual
> resources, which is wrong. Negotiation should really be done at the
> Package level. This is one of those things where thinking HTTPish
> screws you over. A user thinks about a web application or widget as a
> single resource. That there are multiple subresources isn't
> interesting to a user.

Jere wrote:
> Well, I have an issue with thinking about the negotiation at the package
> level, because that means that you need to provide separate downloadable
> packages for each localized widget version. The idea is to provide as
> complete localizations as possible in the one and same widget package, with
> the added suboptimization that material can be reused if desired.

Oh, I'm not saying that you have to provide separate downloadable
packages, just that for the purpose of the user it should be as if the
user downloaded a package and was told:

This package is available in the following languages:
{list}

The useragent then says "it seems that you prefer language X", I will
now ignore all of the other languages that are available in this
package while I'm running it.

The useragent may enable the user to specify a language Y, but doing
that would take effect when the widget is instantiated and again, all
languages not related to Y are ignored.

The user gets to express a list of preferences, but only one is taken,
the rest of the preferences are ignored.

One more example of this disaster as I don't think I included it:

A coworker of mine has his computer configured to use Russian as his
user interface language. We're both in Finland. He ran iTunes which
presented a license agreement.

As far as we were concerned, the license agreement was composed of
three resources:
1. a picture which said (in English) License Agreement
2. picture buttons which said (in Russian) Accept, Reject
3. a license, which was sent in Finnish

The useragent here was iTunes and it managed to do a really terrible
job of negotiating for resources. No user actually wants this result.
As it happens, We (my coworker and myself) don't speak Finnish to the
level of being able to accept license agreements.

Package:

iTunesLicense.wdgt/
 index.html (widget container with iframes)
 fi/licenseText.html (Finnish)
 en/licenseAgreement.html
 ru/accept.png
 ru/reject.png
 fi/accept.png
 fi/reject.png
 en/accept.png
 en/reject.png

This is effectively what was provided by iTunes (in fact, the
accept/reject buttons came from Windows according to the user's select
User Interface Language, the licenseAgreement.html came from
iTunes.exe, and licenseText.html came from a web server which checked
our IP and determined our country).

As far as this iTunes useragent was concerned, the language
preferences were: ru, en, fi.

Myself, I got a version which was equivalent of "en, fi". It wasn't
sufficient for me to accept the license (so all I got was a voucher
for two mp3's from the iTunes store... but only after I accept the
license).

>> So the right algorithm is: 1. collect the full
>> list of all locales for which the package is partially localized. 2.
>> build the list of user requested locales using the algorithm we
>> defined. 3. Use the first matching locale between (1) and (2). 4. Deal
>> with fall back. I think 4 involves telling Authors that if they want
>> to be able to use a /locales/en/ image in /locales/en-us/ then they
>> need a /locales/en-us/images.css that pulls in /locales/en/bird.jpg --
>> however, it's probably best just not to allow it at all.
>
> I'm not convinced how this is the 'right' algorithm... Could you highlight
> how this is different from the current one in the spec?

The key is that the algorithm in the spec will result in authors
accidentally getting an image whose caption doesn't work, because they
weren't aware that such a mix would happen. -- See further examples
below.

> The reason for that is developer error, not system error or design failure.
> Maybe somebody forgot to insert an appropriate image, and the fallback used
> the wrong one. Thatšs what localization testing and Q&A is for.

Oh, hey, we work for the same company. My experience with our testing
is that they miss everything of interest and when they give feedback,
the wrong things are fixed. But I can give examples for most companies
and also various open source projects (in case people object to
biasing toward companies).

> I would
> rather allow for the occasional wrong resource to be shown than make the
> user pay for bloated download packages and duplicated resources. So,
> fallback is important because it reduces duplication.

Falling back to Finnish when I don't speak Finnish is really annoying.
Had you gotten my iTunes license dilemma, it wouldn't have bothered
you, but that's because you speak Finnish. Try moving to China or
Russia and signing up for iTunes.

> The UA locale list handles #1, but therešs not a lot that the spec can do
> for P&C. Authors will always make mistakes, but they need to catch them
> before they ship.

They won't. Having validators warn and user agents provide fatal
errors is actually useful.

Being forced to accept a license you can't understand is not a good thing.


------

One more amusing example of negotiation. An application author wrote
an application for Maemo 4, and we tested it in Maemo 5.

Its functionality can be described like this:

MaemoMapper.wdgt/
 index.html
 en/help.html
 en-GB/go.png
 en-GB/stop.png
 en-US/go.png
 en-US/stop.png

The help says "click the green walk button to continue", in GB there
are red and green icons at street lights indicating whether to cross
or wait, and in US there are orange and white lights.

What actually happened was that the text of the buttons changed
between maemo4 and maemo5 (as with the accept/reject buttons from the
iTunes example).

Received on Friday, 3 July 2009 12:32:31 UTC