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

Re: [widgets] Further argument for making config.xml mandatory

From: <Jere.Kapyaho@nokia.com>
Date: Thu, 19 Mar 2009 17:07:34 +0100
To: <marcosc@opera.com>, <andrew.j.welch@gmail.com>
CC: <Mark.Priestley@vodafone.com>, <public-webapps@w3.org>
Message-ID: <C5E83A66.5628%jere.kapyaho@nokia.com>

On 19.3.2009 17.43, "ext Marcos Caceres" <marcosc@opera.com> wrote:

On Thu, Mar 19, 2009 at 4:36 PM, Andrew Welch <andrew.j.welch@gmail.com> wrote:
>> To be clear, the proposal is:
>> <widget xmlns="http://www.w3.org/ns/widgets">
>>   <name xml:lang="fr">Mon widget</name>
>>   <name xml:lang="en">My Widget</name>
>>   <name>Widget</name>
>> </widget>
> heh... be careful that looks very similar to this "Best Practice":
> "Avoid document formats that store multiple localized versions of
> content within the same document."
> http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc
> :)

That's exactly what I was talking about when I said "even thought the XML i18n
guidelines say it's bad practice,'. However, Addison Phillips, the
Chair of i18n core, said the following in the formal feedback
representing the i18n WG's LC comments for the spec [1]:

"Section 7.4 (Widget) The various language bearing elements such as
<name>, <description>, etc. are of the zero-or-one type. However, it
is typically better to allow any number of these elements to occur,
provided that none share the same xml:lang. This allows for
localization (which is part of the point in allowing xml:lang on the

So we have been blessed by them to do this... umm.... this somewhat
questionable, yet problem solving thing :)

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0259.html

The reason why the I18N BP document frowns upon this is because if you have the material sent for translation, it might (or most probably will) be translated by different people in different places. So it makes coordination a little difficult when all the different language texts are in the same file. That is a big problem if you have substantial amounts of text in the file. In the case of widgets, there might not be such huge amounts of text in the config file, so that's a mitigating circumstance for this horrible negligence. :-)

Let's assess how much translatable text there would be in a config file in the worst case, and then decide if we know well enough to break the best practice or not.

Marcos came up with the following list:

The following elements would be localizable:
widget (but no id or version, derived from root config, if available)

(BTW Marcos, are you sure "content" and "preference" should be there? Also maybe author should be dropped. License I can understand, but probably not to be used to present different versions of a license, just translations of the same license.)

All of these seem to have a fairly limited amount of translatable / localizable content, so would the ease of processing and the general simplification warrant the possible inconvenience in having the text translated? The license seems to be the biggest block of translatable text, and therefore potentially the biggest problem.

(NOTE: A system for widget authoring that is connected to the back-end of the vendor's translation memory / CMS could generate the config file automatically, eliminating the need to translate the actual config files by hand. Translations and other localized material can be assembled into the CMS prior to generating the config file.)

Any further thoughts?

Received on Thursday, 19 March 2009 16:08:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:07:20 UTC