W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2008

Re: [widgets] i18n

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Thu, 15 May 2008 12:08:09 +1000
Message-ID: <b21a10670805141908k3bc43480obde0e3dbd2058288@mail.gmail.com>
To: "Phillips, Addison" <addison@amazon.com>
Cc: "David Clarke" <w3@dragonthoughts.co.uk>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "WAF WG (public)" <public-appformats@w3.org>

Hi Addison,

> A couple of notes:
> 1. The 3066 pattern is language-region, not the other way around.

Oops, that's what I meant :P

> 2. Don't reference RFC 4646. RFCs get obsoleted over time. Instead, reference BCP 47 (RFC 4646's designation in the IETF standards hierarchy).

Ok, good point. Mark Davis also pointed this out. Done.

> 3. Do reference RFC 4647 (as part of BCP 47) and, in particular, the Lookup matching scheme. I think you'll find that this is simple and consistent with existing practice.

Ok, I'll have a read of 4647 and see how I articulate that in the spec.

> 4. You may find that, if you recommend what you intend to, certain applications are hindered.
> In particular, some languages (Chinese!)use varying scripts and need the script subtag from
> RFC 4646. Your recommendation will stand in the way of that. Although a validating
> implementation of 4646 adds a bit of overhead, a "well-formed" implementation isn't nearly
> as difficult (it can be done with an admittedly-very-long regular expression). A better suggestion
> might be to recommend using the 3066 ABNF for "validation" (for its simplicity).

Thanks for pointing that out. We certainly don't want to hinder any
applications or exclude any languages.

In regards to regex, I found this:

If it is known to be suitable, I can make a note in the spec that
implementers might like to look at the unicode regex code. At least in
takes the pain out of trying to decipher the ABNF into regex (or
having to implement an ABNF parser).

Kind regards,

Marcos Caceres
Received on Thursday, 15 May 2008 02:08:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:23:03 UTC