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.bars...@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.we...@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





Reply via email to