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

In the context of the discussion about having a mandatory config file, I proposed to simplify matters even further and have just one config file, with the note that this proposal could be ignored in the interest of time and/or effort. There are pros and cons to both approaches, as Marcos has itemized. While I think it was great of Marcos to consider this proposal, this issue could really be resolved either way, and I certainly don't want this to hold up the spec. Then again, not all have expressed sufficient rationale to back up their opinion, or expressed any opinion at all.

The configuration file does not seem to contain so much translatable data that it would be an issue for localization, and that issue was not raised by the W3C I18N WG either (on the contrary, rather). That was why I thought the simplification was a good idea, but I'm also OK with multiple config files. For the record, you can still count me as backing the idea of a single, mandatory config file, with some multiple elements distinguished by an xml:lang attribute.

--Jere


On 22.3.2009 20.06, "Art Barstow" <art.barstow@nokia.com> wrote:



On Mar 19, 2009, at 12:06 PM, ext Marcos Caceres wrote:

> On Thu, Mar 19, 2009 at 4:52 PM, Andrew Welch
> <andrew.j.welch@gmail.com> wrote:
>>> That's exactly what I was talking about when I said "even thought
>>> the XML i18n
>>> guidelines say it's bad practice,'.
>>
>> Ahh very sorry, I just saw the email after that containing the code
>> sample, and gmail collapses the quoted parts.... my bad.
>>
>>
>>> 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
>>> element)."
>>>
>>> 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
>>
>> That's interesting, because xml:lang seems pretty redundant
>> otherwise!
>
> Alright, lets see a show of hands for this approach! Who supports us
> just having a single config.xml with a bunch of repeated elements, but
> with different xml:langs?
>
> Advantages here are:
>   *  we only need to make very small modifications to the parsing
> model.
>   *  no more searching for config docs in locale folders
>   *  no multiple parsing of config files
>
> Disadvantages:
>  * large, and, if not careful, hard to maintain config files

My experience working with localizers is that separating their data
(concerns) into separate files was a good model and eliminates
potential issues with a localizer accidentally removing or changing
some other part of the config file.

Marcos - what part(s) of the old/current model - i.e. where there is
a root config file plus a config file may also be installed in a
locale-specific directory and the locale-specific config file would
only contain those parts that are localized - are not properly
specified (i.e. needs more spec work)?

All - my take of positions here is as follows. Please let us know if
this data is not correct and if you have not indicated your
preference, please do so ASAP (before the March 26 Voice Conference):

Only one "root" config file: Jere, Marcos

A "root" config file plus one per locale directory: Benoit, Josh

-Regards, Art Barstow