RE: 1st Working Draft of Authoring Techniques for XHTML & HTML Internationalization Published

Hello Jungshik,

Many thanks for these comments. Here is my summary of the discussions we had
during our teleconference relating to your points.


============
Richard Ishida
W3C

contact info:
http://www.w3.org/People/Ishida/ 

W3C Internationalization:
http://www.w3.org/International/ 
 
 

> -----Original Message-----
> From: Jungshik Shin [mailto:jshin@i18nl10n.com] 
> Sent: 10 October 2003 01:09
> To: Richard Ishida
> Cc: public-i18n-geo@w3.org
> Subject: Re: 1st Working Draft of Authoring Techniques for 
> XHTML & HTML Internationalization Published
> 
> On Thu, 9 Oct 2003, Richard Ishida wrote:
> 
> > Congratulations to ourselves !   This announcement has just 
> gone out on
> > the W3C home page.
> 
>   Thank you for your great work ! I just skimmed over it 
> quickly and came up with a couple of comments.
> 
>   In 4.1 Choosing & specifying fonts, it has to be noted that 
> whenever localized font names (family names) are specified 
> (in CSS), all-ASCII font names should be specified alongside 
> because localized font names (in characters outside US-ASCII) 
> are not available on all platforms and nor  recognized by all 
> user agents. For instance, the name of a font returned by 
> Win32 font-related APIs depends on the default
> system locale so that on fonts whose name are   specified in Japanese
> (Chinese/Korean) [1] wouldn't be matched by most [2] 
> user-agents running on non-Japanese(Chinese/Korean) Windows. 
> Another example is fontconfig library used by both Mozilla 
> and Konqueror on Linux and other free Unix. It doesn't yet 
> support international localized font names. Yet another 
> example is XLFD (X11 Logical Font Description) still widely 
> used on commercial Unix despite a number of shortcomings. 
> AFAIK, XLFD doesn't support anything other than US-ASCII in 
> all its fields (including foundry and family name fields). 
> Given all these, it's essential that family names be 
> specified in US-ASCII only strings (along with localized names).

Thanks for bringing this point up.  We will add some information to the
guidelines at the appropriate point.


> 
>  In 14.1 Date & Time, it's adised that 'words for the month 
> be used and an example (02 mar 2004) is given. I'm not sure 
> of the wisdom of this.
> For speakers of European languages, that may be a good 
> advice, but for East Asian users, that doesn't seem to as 
> good (and I'm not sure of other regions/languages). At the 
> minimum, YYYY-MM-DD format (as specified in ISO 8601) should 
> be mentioned as a rather universal and 
> culture/language-neutral alternative.

We felt that YYYY-MM-DD format has a fairly technical bias, and is not
always the preferred form for a particular locale, although it could be
useful in some circumstances.  We also note that pages are in a given
language most of the time, and one might generally expect month names to be
recognised in most situations, though that might not hold for certain
special types of reference page aimed at a reader who doesn't need to
understand the language text. So we think the guidelines should say
something like: consider YYYY-MM-DD, especially when dealing with an
international audience, or use the month name if a local format is more
appropriate.  (Of course, this doesn't apply in quite the same way for CJK,
since the month name is a number plus character. That should be explained.) 

Thanks again for taking the time to comment.

RI


> 
>   Jungshik
> 
> 
> [1] Win32 APIs return localized family names only on CJK windows.
> [2] It's certainly possible that user agents themselves can 
> look 'deep'
> inside a font to figure out ASCII or localized family name 
> even though the OS API doesn't.
>

Received on Thursday, 8 April 2004 15:00:25 UTC