Re: [widgets] element-based localization

Hi Cyril,
I think we also need to clarify what happens when xml:lang="", in that
it must be treated as unlocalized content e.g.

<widget xmlns="http://www.w3.org/ns/widgets"
 xml:lang="en">

   <name short="I'm in english, though not explicitly marked as such!">
    Behaves as if xml:lang="en"
   </name>

   <name xml:lang="pt">
    The declaration of xml:lang="pt" overrides
    xml:lang="en" inherited from the widget element.
   </name>

  <name xml:lang="">
    I am unlocalized content.
  </name>
</widget>

On Fri, Nov 27, 2009 at 8:55 PM, Marcos Caceres <marcosc@opera.com> wrote:
> On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato
> <cyril.concolato@enst.fr> wrote:
>> Hi,
>>
>> I'm trying to implement the element-based localization and I found the spec
>> unclear with regards to the inheritance of th xml:lang attribute and I would
>> like to propose some improved text.
>> First, this attribute is listed as an optional attribute of the widget
>> element but the widget element is not localizable, so one does not
>> understand why.
>
> D'oh! that should be a "localizable: yes". Thankfully, that's there
> for author clarification.
>
>> Then, many other elements (author, preference, icon, content
>> ...) don't list this attribute and are not localizable but they can inherit
>> the value of this attribute.
>
> This is correct, the are inherited but it has not effect because of
> the way elements are gathered in step 7:
>
> [[
> For each range in the user agent locales, starting from the first and
> moving to the last:
>
> If the value of range is not "*", then retaining document order, let
> matching elements be the result of applying lookup to the child
> elements of type name, description, and license that are direct
> descendents of the root element and whose xml:lang attribute matches
> the current range. Append matching elements to the element list.
>
> If the value of range is "*", retaining document order, let
> unlocalized elements be all child elements that are direct descendents
> of the root element that do not have an implicit or explicit xml:lang
> attribute (i.e., match unlocalized content). Append unlocalized
> elements to the element list.
> ]]
>
>> The rest of the elements may have the attribute
>> specified or inherited and use it for localization.
>
> Correct.
>
>> The paragraph explaining this behavior says:
>> "If an element is marked as being localizable via xml:lang with the word
>> "no", it means that the element is not localizable via element-based
>> localization. In other words, exclusion of an xml:lang  on an element
>> indicates that that element is unlocalized content, except in the case
>> whereby a parent element uses xml:lang  (this maintains consistency with the
>> behavior of xml:lang as specified in the [XML] specification). Explicitly
>> declaring xml:lang overrides any xml:lang value inherited from a parent
>> element."
>>
>> I think this paragraph (especially the last 2 sentences) are unclear. I
>> would propose that you clarify as follows:
>
> I agree...
>
>> "As per [XML] specification, the xml:lang attribute can be specified on any
>> element, including in the widget namespace, and the normal behavior for this
>> attribute shall be applied (i.e. inheritance processing, and propagation of
>> the xml:lang attribute on elements on which it is not specified). However,
>> in this specification, the value of the xml:lang attribute (inherited or
>> specified) shall be used for element-based localization only on the elements
>> that indicates "Localizable via xml:lang: Yes.""
>
> I agree with text above. I think we should include it (with a few
> insignificant stylistic changes - see below). It's more precise than
> what is currently there and clears up the ambiguity that Cyril has
> identified.
>
> I've added this to the editor's draft:
>
> "As part of their definition, the XML elements of the configuration
> document are marked as being localizable via xml:lang with either the
> word "yes" or "no". An author can use the xml:lang attribute on any
> XML element, including any element in the widget namespace. During
> Step 7, the user agent will apply the standardized behavior of
> xml:lang specified in the [XML] specification (i.e. inheritance and
> propagation of the xml:lang attribute will occur on child elements on
> which it was not explicitly used - see example below to see how this
> inheritance and propagation works). Regardless of whether xml:lang was
> inherited or explicitly used in an element, a user agent will only use
> the value of an xml:lang attributes for the purpose of element-based
> localization in Step 7 when that element was explicitly marked with
> the text "Localizable via xml:lang: Yes" as part of that elements
> definition."
>
> WDYT?
>
> I would also like to change add the following clarification to widget
> elements xml:lang attribute:
>
> "Using this attribute causes all child elements to inherit this
> attribute and its value (as is the standardized behavior for the
> xml:lang specified in the [XML] specification). However, inheritance
> of the value of this attribute by author, preference, icon, and
> content has no effect during processing in Step 7 (i.e., elements that
> are explicitly marked as "Localizable via xml:lang: no" in this
> specification will be treated as if xml:lang had not been inherited or
> otherwise used)."
>
> WDYT?
>
>> I would also propose to remove the definition of the xml:lang attribute such
>> as:
>> "xml:lang
>>
>>   Authoring Guidelines:It is optional for authors to use the xml:lang
>> attribute with an name element."
>> because even if not written, XML allows specifying this attribute on any
>> element.
>
> The only reason I would keep these is that they serve as a good
> authoring guides (saves authors and those trying to understand the
> spec from reading Step 7... which is by no means light reading! :) ).
>
>> Finally, I would also create some tests in the test-suite to check that
>> inheritance is applied and used or not depending on the element type.WDYT?
>
> I think it is a good idea to create tests for this. If you have
> created some already, please send them to me off-list and I will add
> them. I'm happy to discuss further what form these tests should take.
>
>
> --
> Marcos Caceres
> http://datadriven.com.au
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 27 November 2009 20:14:05 UTC