draft-05: editorial comments (1)

[Addison Phillips [wM]]

Hi Peter,

Thanks for the comments. Some responses below.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no 
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Peter Constable
> Sent: 2004年8月10日 22:36
> To: ietf-languages at alvestrand.no
> Subject: draft-05: editorial comments (1)
> 
> 
> Some minor, editorial issues I've noted so far (section 5 to the end):
> 
> 
> In section 5:
> 
> "The issue of deciding upon the rendering of characters based on the
> language tag is not addressed in this memo; however, if different spans
> of text are not marked with font information, it may be useful to
> provide the ability to mark spans of text with language. For example, a
> rendering engine may use that information in deciding which font to use
> in displaying Han-based ideographs when it encounters mixed
> Japanese-Chinese text that has no attached font information."
> 
> I had two reactions reading this:
> 
> - Even if spans of text are not marked wrt font, it may still be useful
> to mark spans for language (one font may support alternate typographic
> conventions for different languages).

I agree. In fact, see for example http://www.w3.org/International/tutorials/tutorial-lang/#declaring

We can broaden the statement here to cover this.

> 
> - I'm somewhat inclined to say this paragraph is out of place -- that
> details of language-specific are not really character set issues and are
> no more needed than details of language-specific word-boundary detection
> or any other tailored processing. I'll accept that wrt CJK
> language-specific rendering has for many years been closely linked with
> charset issues.
> 
> Both of these reactions might have been mitigated if the paragraph were
> organized differently, giving the CJK context right from the outset.

This paragraph was inserted in response to a comment. I'll have to dig around to find the genesis of it, but it seems to me that you are correct about adding the CJK reference from the start. For example, we could say:

"Rendering of characters based on the content of a
 language tag is not addressed in this memo. Historically, some languages have relied on the use of specific character sets or other information in order to infer how a specific character should be rendered (notably this applies to language and culture specific variations of Han ideographs as used in Japanese, Chinese, and Korean). Among the many benefits of applying a language tag to spans of text, rendering engines may use that information in deciding which font to use
when character set information does not imply the language, isn't available, or in situations where languages with distinct writing traditions are mixed in a single character set."


Or we could move it somewhere. The problem with enumerating some uses of language tags is that it invites enumerating all uses. This document really isn't the place for that, methinks.

> 
> 
> In section 6: 
> 
> "It is important to be able to differentiate between written forms of
> language -- for computer implementations, this is far more important
> than distinguishing spoken forms."
> 
> It is certainly always more important to distinguish written form that
> sub-language variety, but not necessarily more important to distinguish
> written form from language. For instance, the difference between az-Latn
> and az-Cyrl matters less than the difference between az-Cyrl and
> sr-Cyrl.

We could remove the "far more important", which verges on hyperbole and say "for many implementations this is more important than distinguishing the spoken forms."
> 
> 
> In appendix C: For the registry conversion, par. 3 mentions a review
> period of at least 4 weeks, but then par. 8 mentions a review period of
> at least 2 weeks. Unless these refer to distinct review stages, this is
> inconsistent; at best, it's confusing.

These are inconsistent and one of them should be removed. Four weeks is probably more appropriate.

> 
> Also in appendix C: 
> 
> "Tags that contain one or more subtags that do not match the valid
> registration pattern and which are not otherwise defined by this
> document are marked as 'grandfathered' by this document."
> 
> In what sense does the RFC document mark tags? Do we mean that, per the
> terms of the RFC, they will be marked in the registry as grandfathered?

Da. See Doug Ewell's prototype registry and the examples in Section 3.1

> 
> Again, in appendix C, 2/3 of the way down: "The rules governing the
> conversion of RFC 1766 and RFC 3066 registered tags are..." This and
> what follows seems to be largely or entirely a repetition of what
> preceded it.

Yes, that's true. The bulleted list can be stepped on.
> 
> 
> 
> Peter Constable
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages