Re: [widgets] localizing author

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?

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 :)
>
>
>



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

Received on Tuesday, 24 May 2011 09:29:43 UTC