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

On 2.7.2009 15.18, "ext Marcos Caceres" <marcosc@opera.com> wrote:
> Hi,
> At the last teleconf, it was requested that I prepare a list of P&C
> work items that could be distributed among those WG members helping
> with the standardization of widgets.  Here are a parts of emails that
> need responding to (order does not denote priority, though Josh's
> comments seem to be most substantive.):
> 
> 
> On Thu, Jun 18, 2009 at 3:26 PM, timeless<timeless@gmail.com> wrote:
>> 9:01 AM me: 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.

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.

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

>> http://en.wikipedia.org/wiki/Coccinellidae is something I encountered
>> @HEL flying to the F2F, I call it a Lady Bug, but the label (embedded
>> in what I'll call a "picture" said "Lady Bird", and I though it was a
>> mistake, so i took a "photo" of it to post to my friends. If I posted
>> the photo as /en/, the GB/AU/... friends would not get it). Similarly,
>> Nokia has this gem:
>> http://www.webwizardry.net/~timeless/w7/nokia%20communication%20centre%20-%20
>> Use%20the%20Calendar%20view%20in%20Nokia%20Communication%20Center%20to%20mana
>> ge%20your%20device%20calendar%20for%20example%20by%20creating%20editing%20or%
>> 20deleting%20calendar%20entries.png
>> which is because they tried to be clever about sharing a picture
>> between the en-GB installer and the en-US installer.
>>   The results are terribly embarrassing

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. 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.
> 
>> 9:02 AM Put another way. The goal of localization should be twofold:
>> 1. allow the user to express a preference. 2. enable the author not to
>> make the mistakes that Nokia has made

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.

>> 2009/6/22 Krzysztof Maczyqski <1981km@gmail.com>:
>>> such as "en-us", "en-gb", and so on
>> Canonical spelling is "en-US", "en-GB", and so on. Do you intend to require
>> deviating from it?
> 
> There is no canonical spelling in BCP 47, because the tags are treated as
> case-insensitive.
> 
>>> Each item in the unprocessed locales must be a string shorter than eight
>>> characters, in lowercase form
>> I find both of these requirements objectionable. "x-klingon" is 9 characters,
>> country subtags are canonically upper-case and script subtags mixed-case.

Apart from length, it doesnıt matter. Straight quote from BCP 47: ³The tags
and their subtags, including private use and extensions, are to be treated
as case insensitive: there exist conventions for the capitalization of some
of the subtags, but these MUST NOT be taken to carry meaning. ³

--Jere

Received on Thursday, 2 July 2009 13:16:44 UTC