Unifon script?

Doug Ewell doug at ewellic.org
Fri Oct 4 18:05:48 CEST 2013


Peter Constable <petercon at microsoft dot com> wrote:

> The LSTR exists to document valid subtags, but it is structured as a
> machine-readable database so that it can be processed. The reason for
> allowing machine processing is so that software implementations can
> make use of the knowledge contained. The comment field is amenable to
> human readers understanding a given subtag, but is not amenable to
> machine processes getting usable knowledge. If this is a type of
> knowledge that could be useful in software implementations, then that
> may argue for representing it in a machine-readable field, not the
> Comments field. I'd contend that it is useful in software
> implementations. If it were present in LSTR today, my company has an
> implementation that would certainly make use of it.

So, we have three choices:

1. The usual default choice: do nothing, and optionally complain about
the situation.

2. Add Comments fields to the records for 'unifon' and other variant
subtags for phonetic alphabets, encouraging users to include a script
subtag along with this variant.

3. Recharter the LTRU WG and update BCP 47 to add an optional "Script"
field for variant subtags, intended for phonetic alphabets.

A fourth option, requiring all records for phonetic-alphabet variants to
have Prefix fields with script subtags (similar to what we have for
'hepburn' and other romanizations), is not really an option, because it
could not be retrofitted onto the existing variants. Probably there are
not many more phonetic alphabets in reasonably common use that still
need subtags and would benefit from this.

Option 2 might also be expanded to include romanizations, which could
remove the need to specify Prefix fields with script subtags.

Earlier Peter wrote:

> Yes, it would involve [rechartering LTRU]. And a new rev of BCP 47 is
> not low cost, so I'm not pushing for just this change. Something to
> keep in mind if we get other reasons to consider a revision.

We could check the archives over the past four years (since RFC 5646 was
published) to see what other changes have been mooted. That might help
us decide whether the effort is justified. Keeping the scope tightly
limited might help make a revision less painful than the previous two.

Barring that, the most practical option seems to be 2. I realize this
doesn't fully meet Peter's needs, but it might be better than nothing.

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell ­



More information about the Ietf-languages mailing list