W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [widgets] P&C 1.0 Last Call WD: localization comments

From: Jere Kapyaho <jere.kapyaho@nokia.com>
Date: Thu, 22 Jan 2009 17:40:08 +0200
To: public-webapps <public-webapps@w3.org>
CC: ext Marcos Caceres <marcosscaceres@gmail.com>
Message-ID: <C59E5FF8.4813%jere.kapyaho@nokia.com>

Hi Marcos,

for the LC disposition of comments:

I checked against the latest Editor's Draft (as found at
http://dev.w3.org/2006/waf/widgets/); all the concerns I raised below have
been addressed. Thank you.

Two *very* minor points about the example in section 6.5:

- "The config.xml file at the root configures English (en/, en-gb/) and
Korean versions of the widget." -- there's that Korean again :)

- Make all the paths on the right side either absolute or relative. (c.f.
'/locales/en-au/cats.html' and 'locales/es/gatos.html').


On 17.1.2009 22.56, "ext Marcos Caceres" <marcosscaceres@gmail.com> wrote:

> Hi Jere,  
> On 1/14/09 3:28 PM, "Jere Kapyaho" <jere.kapyaho@nokia.com> wrote:
>> Hi Marcos,
>> I have (still) a couple of concerns about the localization section of
>> Widgets Packaging & Configuration Last Call WD of 20081222.
>> /1/ Is the following statement in [1] as it should be?
>> "Author requirements: Localized folders must be at the root of the widget (a
>> localized folder not at the root of the widget will be treated as an
>> arbitrary folder)."
>> I think it should now read:
>> "Localized folders must be placed inside the container for localized content
>> (...)".
> Fixed. 
>> /2/ I was looking at the localized widget example in the same section (it's
>> non-normative, but important nonetheless), and it seems that the left and
>> right sides of the example don't agree. The paths on the right are absolute
>> from the root, not the container.
> Fixed. 
>> The right side shows en-au, but that is not found on the left side. The
>> first bullet of the example mentions Korean, but that does not seem to be
>> present. Should it be Spanish instead?
> Fixed.  
>> Finally, it's not obvious which of the files shown (if any) is the start
>> file, because the content of config.xml is not shown.
> I've now added /config.xml to the right side. It includes a <content/>
> element which hopefully makes things more clear.
>> /3/ This is a potentially confusing statement:
>> "At runtime, the widget user agent will set the (HTML or XML) base of the
>> start file to the localized folder (even if the start file does not reside
>> inside the localized folder)."
>> I assume in this case "the localized folder" means the one determined in
>> Step 6, right? This might not be obvious from the context, it requires a
>> trip to the text of Step 6.
> This is correct. I've added a link to step 6 in the text: "please refer to
> step 6" (does that help at all or should I elaborate more on it in the
> spec?)
>> /4/ Since BCP47 tags are case-insensitive, it might be good to normalise all
>> their occurrences to lowercase, to avoid any confusion.
> Ok, I wrote into step 3 that the wua-language list must be normalized to
> lowercase form. I modified step 6 also so the comparison is done in lower
> case. Can you please check that it is ok?
>> /5/ Is there value in being able to have multiple config.xml documents,
>> instead of just one, and tagging the relevant elements with a BCP47 tag? The
>> example mentions "different author and license", which could be expressed in
>> one file. If you have a pointer to some earlier discussion that resolves
>> this, it's fine. Or do you think it would make the config.xml document too
>> bulky?
> Although we have had these discussions in the past, I don't have pointers
> but I am happy to summarize our thinking here. There are a number of reasons
> why we went with the multiple config file approach:
>  1. the XML I18n best practices guidelines says it that we should have
> multiple documents. See http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc
>  2. Like you said, makes the config files less bulky and, IMHO, easier to
> maintain.
>  3. Makes processing the XML easier and more predictable.
> Also, in a separate email I noticed you raised concerns about the use of
> "not required" in the Widgets digsig spec. I noticed that I had introduced
> the same problem into the the P&C spec. I have gone through and changed all
> instances of "not required" to use the word "optional". I'll make sure that
> doesn't happen in the other specs too.
> For the purpose of LC disposition of comments, can you please indicate if
> you are satisfied with the working group's response.
> Kind regards,
> Marcos 
Received on Thursday, 22 January 2009 15:45:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:50 UTC