Re: [widgets] localizing author

On Tue, 24 May 2011 11:28:55 +0200, Marcos Caceres  
<marcosscaceres@gmail.com> wrote:

> Hi Charles,
>
> As this was a comment on a Last Call draft, I just wanted to close the
> loop on this so we can record it in the Disposition of Comments.
>
> Are you ok with leaving localization of the <author> element until
> version 2 of the spec? Are you ok for the specification to progress
> down the REC track?

Yep :|

Cheers

Chaals

> Please let us know by the 27th of May; otherwise we will have to
> assume you are ok with that (which I'm hopeful you are:)).
>
> Kind regards,
> Marcos
>
>
>
> On Thu, May 5, 2011 at 12:02 PM, Marcos Caceres
> <marcosscaceres@gmail.com> wrote:
>>
>> On Thursday, May 5, 2011 at 6:38 AM, Charles McCathieNevile wrote:
>>> On Wed, 04 May 2011 18:29:50 +0200, Marcos Caceres
>>> <marcosscaceres@gmail.com> wrote:
>>>
>>> > > Hi,
>>> > >
>>> > > I just realised that I actually localise my own name...
>>> > > But I cannot do that in config.xml. Likewise, I would
>>> > > like to localise the href for me which would be possible if I could
>>> > > localise the author element but isn't at the moment.
>>> >
>>> > Yes, this was a mistake.
>>>
>>> If we were at REC I would suggest this go into an erratum...
>>
>> Although it seems like a small thing, it's a significant change to the  
>> parsing model for this kind of element. And if we change it for author,  
>> we should also change it for <icon> too.
>>
>>>
>>> > > I don't know if this is too late for the current version, in which  
>>> case
>>> > > please log it as an issue for the future.
>>> >
>>> > I think it is too late for this version. We have runtimes now at 99%  
>>> and
>>> > even 100% conformance and adding this would make most runtimes
>>> > non-conforming. I think its more important now to push this spec to  
>>> REC
>>> > and address these kinds of cases in a future version of the spec.
>>>
>>> Do we have a test for this? I propose that we allow our run-time (and
>>> other implementations, such as the validation used by Opera stores) to
>>> localise author, and if that makes us non-conforming we're letting  
>>> good be
>>> an enemy of better (and the argument that we have conformant run-times
>>> then looks weaker). If we don't have a test for it, then we know there  
>>> is
>>> a requirement in our spec that isn't tested anyway.
>>
>> There are no tests that combine xml:lang and the author element - so I  
>> think you are in the clear wrt conformance (this also means that spec  
>> is in the clear to allow this feature to be added later). So, :D. There  
>> are tests to make sure that only the first author element in document  
>> order encountered is selected:
>>
>> http://dev.w3.org/2006/waf/widgets/test-suite/#user-agent/ta-LYLMhryBBT/tests
>>
>> So, adding the behavior you are proposing could keep Opera conforming  
>> for the purpose of the test suite: when <author> elements with no  
>> xml:lang are present in a config.xml, behave as the spec says today.  
>> Otherwise, behave as if <author> was localizable via xml:lang.
>>
>>>
>>> In paticular, since we have at least one live product (addons.opera.com
>>> submission process) that validates against the existing schema, we have
>>> the choice of either supporting the spec or supporting best practice  
>>> here.
>>> What would you prefer us to do?
>> If I could have one wish, I wish Opera would first claim 100%  
>> conformance by fixing the empty <name> element bug. Then, after that,  
>> we create a new spec that makes both <author> (and <icon>!) localizable  
>> via xml:lang. Existing content will continue work with the introduction  
>> of this new behavior and can even be kept backwards compatible with  
>> existing runtimes if a few simple rules are followed during authoring.  
>> However, if you can get both implemented in a timely manner, that's  
>> also a huge win for authors.
>>
>>>
>>> > > Changing it to allow localisation would mean a change to the  
>>> schema -
>>> > > and at least to Opera's implementation. I haven't yet checked (I  
>>> only
>>> > > realised I want to do this but it isn't allowed today) whether we  
>>> have
>>> > > any preference for making that change now or later.
>>> >
>>> > I think we should definitely add this to any future versions of the
>>> > spec. In fact, authors could actually start using multiple localized
>>> > author elements today and have them work in the future.
>>> >
>>> > If it is ok with you, we will add this to a future version of the  
>>> spec?
>>>
>>> Notwithstanding the above, given that if you do add localised versions  
>>> the
>>> required behaviour is clear in v1
>>> processing, I can live with that if the group decides to take that
>>> approach.
>>>
>>> Pity though. Turns out we're not infallible yet ;)
>> It's amazing the things one finds when people actually start using  
>> stuff we specify :)
>>
>>
>>
>
>
>


-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 24 May 2011 11:00:13 UTC