W3C home > Mailing lists > Public > www-international@w3.org > July to September 2006

Re: Comments on Working Draft http://www.w3.org/TR/2006/WD-i18n-html-tech-lang-2006

From: Addison Phillips <addison@yahoo-inc.com>
Date: Mon, 25 Sep 2006 14:15:19 -0700
Message-ID: <451846E7.5080709@yahoo-inc.com>
To: CE Whitehead <cewcathar@hotmail.com>
CC: www-international@w3.org

Some comments follow...

CE Whitehead wrote:
> *Content*
> 1.
> You asked whether or not the language code mul (multiple languages) should be 
> mentioned.  I felt that it should since it is out there.  As for recommending 
> it, normally, I do not think mul is a good language tag, since it is not 
> specific enough to be useful.


> However, I have a document I transcribed from an image of a Renaissance French 
> (different than either modern or medieval French; thus no language tag is 
> available); unable to find an experimental tag in use as of yet, I created the 
> experimental tag x-fr-rn  but firstly, I have added summaries of the text in 

Note that RFC 4646 frees you from this trap, somewhat. You could use the 
only partially obscure tag "fr-x-rn". This exposes that the content is 
in French, but also that it has some interesting differences.

> English; secondly experimental tags may not be that useful .  Also I'd like to 
> target both English speakers, French learners who speak English, and possibly 
> native French speakers who would like to see this particular document about the 
> French in North America.   So I've considered using the language 
> tag "mul' somwhere here.  But it's useless as a text-processing language, of coruse.

Usually, if you mix languages together, it is better to use a list than 
the rather useless 'mul' subtag. For example:

   <meta http-equiv="Content-Language" content="fr,en" />

This is much better at indicating the intended audience than "mul".

> 3. 
> Would not it be a best practice to specify font whenever the user agents might 
> be unaware of the various language tags as in the case of the Chinese tags, 
> zh-HANS, zh-HANT and thus might choose the wrong font (Best Practice 13 in 
> Section 7, "Choosing Language Values")?

Font names are always a problem. You can't be sure what is installed on 
the user's machine(s). Ultimately the user-agent might be forced to fall 
back to detecting the language so that it can assign a font based on 
language, if none of the named fonts are available. While providing for 
a specific font in your CSS is a good idea, one should always provide a 
generic font like "serif" somewhere in the list and expect the browser 
to do its best. Tagging with proper language tags will help hint the 
browser to the right selection.

And with the advent of IE7 and other updated browsers, user-agents can 
actually do something useful with the script subtags.

> 4.
> sometimes you state that the metadata about the language of the targeted 
> audience should be stated in the HTTP content-language header (see 3.1, last 
> paragraph) and sometimes you state that it is not determined where it should be 
> stated as the use of the meta tags is becoming more and more widespread (since 
> even some tools for creating pages are sticking these in) (see 4.2).  Then in 
> Best Practice 8 (section 6) you recommend using the meta tag.  So three 
> different recommendations for how to to this--seem to be conflicting to me.

The HTTP header is good to set, if possible. However, since it is 
usually set outside the document, it is often wrong.

The HTML <meta> tag is good to set, and, since it is included in the 
document, less likely to be wrong. It can't hurt to have set it, even if 
the server announces the language.

And some content might not have either mechanism available...

> 5. 
> A small note on setting the text processing language in the html element:  the 
> html element is not always available for this purpose--in for example cases 
> where your page is embedded by the host into its page, which is quite common I 
> think (a site that does this with html pages is teacher web, 
> http://teacherweb.com ). 

Yes, but such page surgery should be made known to the content author 
(so that they can, for example, include an additional xml:lang/lang 
attribute on the <body>).

Best Regards,


Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.
Received on Monday, 25 September 2006 21:15:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:27 UTC