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

[ESW Wiki] Update of "its0504ReqCulturalAspects" by MasakiItagaki

From: <w3t-archive+esw-wiki@w3.org>
Date: Wed, 15 Jun 2005 20:34:16 -0000
To: w3t-archive+esw-wiki@w3.org
Message-ID: <20050615203416.23151.48649@localhost.localdomain>
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "ESW Wiki" for change notification.

The following page has been changed by MasakiItagaki:
http://esw.w3.org/topic/its0504ReqCulturalAspects


------------------------------------------------------------------------------
  == Notes ==
  RFC 3066bis called “Tags for Identifying Languages” ([http://www.inter-locale.com/ID/draft-phillips-langtags-10.html#variant]), defines the vast details of the structure and usage of language tags extended from RFC 3066. This proposes ways to define extended language subtags, such as variant subtags, region subtags and private use subtags, which could be solutions for the issues described above. See also supplementary information for RFC 3066bis [http://users.adelphia.net/~dewell/rfc3066bis-codes.html].  
  
- '''[MI] Felix previously had the following comment: "I would add s.t. like: 'The possible value of the attribute will not be predefined.' I think this is the only way to do this, because otherwise a general model of these cultural aspects would be necessary - that's seems to be impossible to me." Now, please notice that the NOTES section refers "variant subtags." I might need some more discussion on this since some argue that allwoing variants for this type of information is not a good idea (because localization tools cannot know what exactly are all properties). For example, when someone defined "en_US_south" as cultural indication for southern US English (I'm just making this up, OK?), how does the tool know "south" is for souther English? So allowing such variants may disrupt tool functionality. So I would like to discuss this point with you.'''
- 
- '''[[FS-''' The RFC 3066bis defines a grammar for language tags. As you parse a language tag, you can /  must (?) use this grammar to separate the various kinds of subtags. I.e., you can separate scripts, regions, variants, etc. But it is not possible to make finer distinctions between variants, e.g. variants which describe writing styles versus variants which describe other cultural preferences. RFC 3066bis states that the interpretation of the language tags relies on the respective IANA registry, although other interpretations are possible. The question if whether we want to rely on the IANA registry, ISO 15924, ISO 639 (which is currently under revision) or want to make our own interpretations. Any opinion?''']]'''
- 
  == Quick Guideline Thoughts ==
  
Received on Wednesday, 15 June 2005 21:50:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:12:45 GMT