W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

[widgets] CfC: Dropping xml:lang on icon elements; deadline Oct 14

From: Arthur Barstow <art.barstow@nokia.com>
Date: Sat, 10 Oct 2009 08:11:46 -0400
Message-Id: <760472C0-B6C5-4BEB-BE5F-6D674784D1A5@nokia.com>
To: public-webapps <public-webapps@w3.org>
This is a Call for Consensus to accept the P&C change request Marcos  
provides below including his further clarification of the proposal at  
[1].

Please use the latest P&C TSE [TSE] as the context/target of this  
change request.

As with all of our CfCs, positive response is preferred and  
encouraged and silence will be assumed to be assent. The deadline for  
comments is October 14.

-Regards, Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 
0125.html
[TSE] http://dev.w3.org/2006/waf/widgets/Overview_TSE.html


Begin forwarded message:

> From: ext Marcos Caceres <marcosc@opera.com>
> Date: October 9, 2009 7:33:13 AM EDT
> To: public-webapps <public-webapps@w3.org>
> Subject: [widgets] Dropping xml:lang on icon elements
> Reply-To: "marcosc@opera.com" <marcosc@opera.com>
> Archived-At: <http://www.w3.org/mid/ 
> b21a10670910090433r4bab2c76ga762a182fe58b1d5@mail.gmail.com>
>
> During implementation, we found unnecessary complexity/redundancy with
> the combination of icon + xml:lang + folder based localization.
>
> The problem is that icons are specified as a list of icons, with
> different media types, of which the AU selects the one that is most
> suitable. Adding folder-based localization to that makes the list
> two-dimensional, which is easy to handle. We just use the same path
> lookup as for any other resource, i.e once we have decided that we
> want the SVG version, we just pick the appropriate icon from the most
> relevant localized path.
>
> If we add xml:lang to that, we get a three-dimensional list, from
> which we need to find not only the best media type, we need to find
> the best language declaration, and then see if it is available in a
> localized folder.
>
> So, if I have these this icon defined:
>
> <icon src="bork.svg" xml:lang="sv">
>
> And these files:
>
> locales/en/bork.svg
> bork.svg
> icon.svg
> icon.ico
>
> Language list set to "en,sv"
>
> I would end up with picking "locales/en/bork.svg" instead of
> "default.svg" as the xml:lang pass would select the bork.svg as being
> the localized one (whereas the others are unlocalized), while the
> folder-based lookup would pick the one in locales/en as the "en"
> locale is preferred.
>
> For simplicity, keeping a two-dimensional lookup of media type 
> locales folder makes the implementation easiest and yields the least
> surprises.
>
> Proposed changes to spec:
>
> 1. The icon element would not support xml:lang. So:
> [[
> Localizable via xml:lang:
>   Yes, multiple repetitions of the same xml:lang value are allowed.
> ]]
>
> Becomes:
> [[
> Localizable via xml:lang:
>   No. Relies on folder-based localization.
> ]]
>
> 2. the concept of "elements are grouped by language" gets removed from
> the Element-Based Localization section.
>
> 3. In Step 7, step 7 gets dropped.
>
> -- 
> Marcos Caceres
> http://datadriven.com.au
>
Received on Saturday, 10 October 2009 12:12:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT