Re: [widgets] Base folder and resolution of relative paths

Hi Francois,
FWIW, we have re-factored the i18n model around your "act as a HTTP
server" proposal. I'm in the middle of spec'ing it, which is why we
haven't emailed you back yet. We are applying the "per resource"
localization model to both files and configuration document elements.
I'll email you as soon as I have something concrete down. If you want
a sneak peak, read the following sections:

Step 5 - Derive the User Agent's locale
Rule for finding files within a widget package

In essence, Step 5 decomposes language tags to emulate the behavior of
BCP47 Lookup, so for example, an unprocessed locales lists that
contains:
   "en-us,en-au,en,fr-ca,zh-hans-cn",

would decompose to:
    "en-us,en,en-au,en,fr-ca,fr,zh-hans-cn,zh-hans,zh",

and then normalize (remove duplicates, from right to left) to:
    "en-us,en,en-au,fr-ca,fr,zh-hans-cn,zh-Hans,zh".

The normalized list above becomes the search space for the "rule for
finding files within a widget package". So, if you want to find file
"cat.png", you search:

/locales/en-us/cat.png ?
/locales/en/cat.png ?
/locales/en-au/cat.png?
/locales/fr-ca/cat.png?
/locales/fr/cat.png?
/locales/zh-hans-cn/cat.png?
/locales/zh-Hans/cat.png?
/locales/zh/cat.png?
/cat.png?

If there is a "hit", then return it... if no, ignore the file (behave
like a 404).

Kind regards,
Marcos


On Tue, May 19, 2009 at 10:32 AM, Francois Daoust <fd@w3.org> wrote:
> Hi Jere,
>
> Here are a few +1.
> I'm not sure I can be of any further help to be honest. You seem to have
> raised all the questions that needed to be raised, and weighed the benefits
> and drawbacks of various proposals accordingly, and I'm not an expert in
> that field.
>
>
> Jere.Kapyaho@nokia.com wrote:
>>
>> Hi Francois,
>>
>> the idea of treating the widget package essentially as a local HTTP server
>> in terms of resources is quite interesting, although like you said there
>> will be differences. In terms of localized resources, it seems a good
>> strategy to use the same mechanism as HTTP and Accept-Language to select
>> localized resources. I donąt know if anyone has done it like this before
>> in
>> the context of an application; maybe not. But somehow I think we donąt go
>> all the way to q values. (?)
>>
>> The most important concept here is really that the locale (or language
>> tag,
>> if you will) is specific to any given resource. That does have the risk of
>> having partially localized applications, as you observed, but that is
>> really
>> the developerąs concern. They just need to make a concerted effort to
>> localize all that is needed.
>
> +1.
>
>
>> Of course there will always be widgets that have nothing localized, so the
>> mechanism must allow the fallback content to be found as the last step of
>> the lookup. The drawback there is that if resources are always looked for
>> according to the UA language list, it might be wasted effort (and a
>> performance hit) for those widgets that donąt have anything localized. The
>> search would go all the way from the deepest branch to the root in vain
>> before finding the fallback content.
>
> I don't think performance will be that impacted (parsing/rendering resources
> is probably times longer than looking up for resources) but that's correct.
>
>
>> Iąm thinking the widget locale (as derived from the UA language list)
>> should
>> be organized by primary subtag so that the most specific tag comes first,
>> like so: łen-us, en, fr-ca, fr-fr, fr˛. At least Marcos seemed to like
>> this
>> idea. That would simplify things by making the base folder essentially the
>> first tag in the widget locale. (Or could this be folded to just "en-us,
>> fr-ca, fr-fr"? Content negotiation should know to drop the subtags
>> successively anyway.)
>
> It looks good, but I don't feel I know enough on locale specificities to
> take any position. Up to you! ;)
>
>
>> Assumptions/premises:
>> - The content negotiation is applied only to widget: URIs (incidentally,
>> would a relative URI inside widget content then always be considered a
>> widget: URI?)
>
> Not sure what you're referring to with "content negotiation", here. Why
> would content negotiation not be applied to external http: URIs? Widgets
> that communicate with an external server run by the company that produced
> the widget should be common. The same localization mechanism would probably
> be applied both in the widget and server-side.
>
>
>> - When referring to content inside the widget package, the
>> Olocales/some-language-tagą part is never included in the URI. Instead,
>> the
>> content negotiation mechanism should kick in and find the resource given
>> just a relative URI like 'flag.png'.
>
> +1.
>
>
>> - If the content negotiation finds no localized content (i.e. there is no
>> requested representation for the resource), a resource with the specified
>> name in the root of the widget is used. If not present, it is probably an
>> error.
>
> +1 without the final "probably". If not present, it is an error.
>
>
>> I'm trying to help Marcos hammer out these things in the P&C spec, so I
>> really appreciate your feedback.
>
> Good luck! :)
>
> Francois.
>
>



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

Received on Tuesday, 19 May 2009 08:52:52 UTC