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

On Fri, Jul 3, 2009 at 2:31 PM, timeless<timeless@gmail.com> wrote:
> 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.
>

I talked to our localization guys about this, they said that is
definitely not a good thing. They said any content is better than no
content, even if there is a mismatch.

> 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.

I agree, but that is Apple's fault. Yes, the model allows things like
this to happen. But I think it's better thank getting no license at
all.

> 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).
>

I still feel that this is an author-level error.

>>> 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.

I agree this sucks, but like I said, my preference is to have
"something" shown. When authors make such mistakes, then can easily be
patched via updates, which is what updates are for.

>> 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.

<mostly rant>
I think that happens in native languages as well. I imagine very very
very few people in the world have ever sat down and gone "hmm... what
am I agreeing to here. Lets see..." :) Even if they did, a ULA would
not make much sense to an average user. If licenses were
comprehensible, I bet no one would click "I Agree". And I guess that's
another reason that Creative Commons licenses are in a picture-book
friendly form that most can (kinda) understand.
</mostly rant>

I agree. But again, iTunes should do something about that. It can't be
the case that widgets would not allow me to ship a widget because I
can't get something translated. If that was the case, I would still
include the wrongly localized content just so I could ship (and just
say, "centre, center, meh! Only a few will notice, so I'll fix that in
the next update.").

> ------
>
> 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).
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 3 July 2009 16:36:28 UTC