RE: [widgets] Re: i18n comments:

Please do not reply to this email.  To make it easier to follow comment
threads I will send out separate emails for each comment in just a few
minutes.  I will also add the first three comments to our review table,
since they are new.

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/




> -----Original Message-----
> From: Phillips, Addison [mailto:addison@lab126.com]
> Sent: 28 May 2010 06:30
> To: art.barstow@nokia.com; ext Richard Ishida
> Cc: 'Felix Sasaki'; 'Marcos Caceres'; 'Robin Berjon'; 'Steven Pemberton';
'Doug
> Schepers'; 'Charles McCathieNevile'; 'www-archive'
> Subject: RE: [widgets] Re: i18n comments:
> 
> Dear Art, et al,
> 
> Sorry for the delay in responding. I have reviewed the 27 May 2010 draft
> posted by your editor in addition to the previous draft. I have only a few
> minor, editorial comments:
> 
> 1. Language tags are presented as lowercase. While case has no meaning in
> language tags, they are typically canonicalized (and are recommended to
use)
> the case conventions in BCP 47. See section 2.1.1 [1].
> 
> 2. In Section 8.4 there is an example of the empty language tag with the
> comment "The user agents will treat this as unlocalized content." This
should
> be "user agent" singular. More importantly, there should be a distinction
> between "unlocalized" and "non-linguistic" or "undetermined" or at least
> "default content" (which is what you mean). Note that the tag "und"
> represents text whose language cannot be determined. I would suggest
> "default content" here (and elsewhere).
> 
> 3. In Section 9.1 there is a term "i18n string". We typically do not like
the term
> "i18n" to be used for anything (my car's license/number plate and my .sig
are
> exceptions to this rule ;-)), and, in this case, it doesn't convey any
meaning. I
> would prefer the term "localizable string", "localizable", or "language
string".
> 
> 4. I personally disagree with Richard's comment #20 [2]. The empty
language
> tag is related to locale fallback in that it represents the root of the
locale
> hierarchy, a position you could fill with "i-default", save that that
value doesn't
> play nicely with BCP 47 fallback. The xml:lang="" is the default content.
I don't
> agree that this is "unlocalized", which is your description. See my
comment #2
> above.
> 
> In general, this document is greatly improved and I endorse your
publication
> of it. Thanks for all of your help in supporting internationalization in
this spec.
> 
> Regards,
> 
> Addison
> 
> [1] http://tools.ietf.org/html/bcp47#section-2.1.1
> 
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N, IETF IRI WGs)
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> 
> > -----Original Message-----
> > From: Arthur Barstow [mailto:art.barstow@nokia.com]
> > Sent: Wednesday, May 26, 2010 5:54 AM
> > To: ext Richard Ishida; Phillips, Addison
> > Cc: 'Felix Sasaki'; 'Marcos Caceres'; 'Robin Berjon'; 'Steven
> > Pemberton'; 'Doug Schepers'; 'Charles McCathieNevile'; 'www-
> > archive'
> > Subject: Re: [widgets] Re: i18n comments:
> >
> > Richard - thanks for sending your comments.
> >
> > Addison - Richard indicates below you are going to respond (i.e.
> > follow-up). What is your plan to do so?
> >
> > -Art
> >
> > On 5/20/10 12:32 PM, ext Richard Ishida wrote:
> > > Hi Art,
> > >
> > > We discussed this at the i18n telecon last night and Addison has
> > an action
> > > to respond to you quickly to (I hope) let you know that all is ok.
> > >
> > > However, I gave the document one more read through myself this
> > afternoon
> > > just for good measure, and I noticed a small number of editorial
> > nits that I
> > > will send along in a few minutes in separate emails.
> > >
> > > One additional comment that's not worth a separate email: Yves
> > Savourel's
> > > name is missing the final 'l' in the acknowledgements section.
> > >
> > > As always, a summary of all our comments can be found at
> > > http://www.org/International/reviews/0907-widgets-pc/  with links
> > to email
> > > threads.  Comments on a white background are deemed to be
> > fixed/closed.
> > >
> > > I added one substantive comment (number 20) that reflects
> > something I
> > > mentioned in an email on 26th March, but I am assuming that it is
> > now too
> > > late to change it, so I marked the comment as closed.  (If it is
> > not too
> > > late to change it, please consider doing so, of course.) I will
> > send an
> > > email for that one too, just to keep the books tidy.
> > >
> > > Cheers,
> > > RI
> > >
> > > ============
> > > Richard Ishida
> > > Internationalization Lead
> > > W3C (World Wide Web Consortium)
> > >
> > > http://www.w3.org/International/
> > > http://rishida.net/
> > >
> > >
> > >
> > > From: Arthur Barstow [mailto:art.barstow@nokia.com]
> > > Sent: 12 May 2010 17:14
> > > To: Richard Ishida; Addison Phillips; Felix Sasaki
> > > Cc: Marcos Caceres; Robin Berjon; Steven Pemberton; Doug Schepers;
> > Charles
> > > McCathieNevile; www-archive
> > > Subject: Fwd: [widgets] Re: i18n comments:
> > >
> > > Hi All,
> > >
> > > Marcos has completed all of the changes to the Widget Packaging
> > and
> > > Configuration (P&C) spec related to the new<span>  element and
> > dir attribute
> > > and the removal of the ITS references. The latest Editor's Draft
> > that
> > > includes these changes is:
> > >
> > > [ED]http://dev.w3.org/2006/waf/widgets/
> > >
> > > Would the I18N WG please review the changes and submit comments
> > to
> > > public-webapps?
> > >
> > > Given the last formal publication of this spec was a CR and we
> > consider the
> > > <span>  and dir changes as a replacement for ITS, our plan (once
> > we have
> > > sufficient implementation data) is to move directly to PR and not
> > publish
> > > another LC or CR. As such, we want to know if the I18N WG sees
> > any issues
> > > with [ED].
> > >
> > > -Thanks, Art Barstow
> > >
> > > Begin forwarded message:
> > >
> > >
> > > From: Arthur Barstow<Art.Barstow@nokia.com>
> > > Date: April 6, 2010 10:05:33 AM EDT
> > > To: Addison Phillips<addison@amazon.com>, Marcos Caceres
> > > <marcosc@opera.com>, Felix Sasaki<felix.sasaki@fh-potsdam.de>,
> > "Martin J.
> > > Dürst"<duerst@it.aoyama.ac.jp>, Richard Ishida<ishida@w3.org>
> > > Cc:public-i18n-core@w3.org, public-webapps<public-webapps@w3.org>
> > > Subject: [widgets] Re: i18n comments:
> > >
> > > Hi Marcos, All,
> > >
> > > Has the I18N Core WG reviewed Marcos' latest proposal? If yes,
> > where can we
> > > find their comments; if no, when can we expect a reply?
> > >
> > > -Art Barstow
> > >
> > > On Mar 30, 2010, at 11:07 AM, ext Marcos Caceres wrote:
> > >
> > >
> > >
> > > On 29/03/10 5:16 PM, Phillips, Addison wrote:
> > > This doesn't make any sense to me. I think you are over-thinking
> > this.
> > >
> > > The author element contains the author's *NAME*. It can also
> > include an href
> > > and an email attribute. UTR#36 refers explicitly to IRIs and IDNA
> > addresses,
> > > which would be the values of these attributes. However, it does
> > NOT refer to
> > > plain text (the body of the element 'author') which is what the
> > 'dir'
> > > attribute really applies to. To not provide bidirectional
> > overrides for the
> > > author's name strikes me as incredibly short sighted, given that
> > you can
> > > override any higher-level element. To have one place in your
> > configuration
> > > document that requires controls is not to improve security, it is
> > to reduce
> > > usability.
> > >
> > > I've updated the spec and the RelaxNG to include "rlo" and "lro".
> > >
> > > It would make far more sense for you to cite UTR#36 with regard
> > to an
> > > implementations presentation of the href or email attributes,
> > suggesting (or
> > > forbidding) the application of the dir attribute to these values.
> > But the
> > > body of the<author>   element needs the bidi markup and should
> > not depend on
> > > Unicode bidi controls.
> > >
> > > I trashed the old note, made this new note.
> > >
> > > [[
> > > Note: Implementations intending to display IRIs and IDNA
> > addresses found
> > > in the configuration document are strongly encouraged to follow
> > the
> > > security advice given in [UTR36]. This could include, for example,
> > > behaving as if the dir attribute had no effect on any IRI
> > attributes,
> > > path attributes, and the author element's email attribute.
> > > ]]
> > >
> > > IRI attributes, path attributes are defined in the specification.
> > >
> > > Any better?
> > >
> > > Kind regards,
> > > Marcos
> > >
> > >
> > > --
> > > Marcos Caceres
> > > Opera Software
> > >
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG -www.avg.com
> > > Version: 9.0.819 / Virus Database: 271.1.1/2866 - Release Date:
> > 05/11/10
> > > 19:40:00
> > >
> > >
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.819 / Virus Database: 271.1.1/2898 - Release Date: 05/26/10
> 19:26:00

Received on Friday, 28 May 2010 06:35:10 UTC