From is@sac.sfbay.sun.com Fri Oct 30 17:40:58 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V0ewcm027925 for ; Fri, 30 Oct 2009 17:40:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9V0evAj005986; Fri, 30 Oct 2009 17:40:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSC00401SK9MO00@nwk-avmta-2.sfbay.sun.com>; Fri, 30 Oct 2009 17:40:57 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSC00KC7SK8YS90@nwk-avmta-2.sfbay.sun.com>; Fri, 30 Oct 2009 17:40:56 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9V0eus7007567; Fri, 30 Oct 2009 17:40:56 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V0etCg027919; Fri, 30 Oct 2009 17:40:55 -0700 (PDT) Received: (from is@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n9V0etcg027915; Fri, 30 Oct 2009 17:40:55 -0700 (PDT) Date: Fri, 30 Oct 2009 17:40:55 -0700 (PDT) From: Ienup Sung Subject: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Message-id: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7558 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Locale name alias support at libc 1.2. Name of Document Author/Supplier: Author: Ienup Sung 1.3 Date of This Document: 30 October, 2009 4. Technical Description OVERVIEW When Solaris systems are newly introduced into a heterogeneous environment dominated by other operating systems, say, an IBM shop or a HP-UX shop, due to that the locale names being used at ours and other platforms such as AIX, HP-UX, and various Linux distributions are slightly different in many cases, even though we have compatible and acceptable locales at Solaris, existing users' locale environment variable settings of such shops are not honored causing an operational interoperability/compatibility issue especially in accepting Solaris systems. As an example, while Solaris uses fr_FR.UTF-8 as the locale name for French France UTF-8 locale, IBM AIX uses FR_FR and HP-UX 11.11 and RHEL 5.4 use fr_FR.utf8. (It also appears that glibc based Linux distributions allow some variations of the locale names in codeset part of locale name via some kind of codeset name normalization mechanism hence accepting not only fr_FR.UTF-8 and fr_FR.UTF8 but also fr_FR.utf8.) One way to resolve this interoperability/compatibility issue would be creating and maintaining thousands of locale name related symbolic links at our locale directories but that will be quite messy and very difficult to maintain. Hence, this project proposes to have a transparent locale name alias support mechanism at libc with embedded locale name mapping tables as outlined at below to remedy the interoperability/compatibility issue and aid users who want to migrate from other platforms to Solaris. TECHNICAL DETAILS Currently, when a locale selection is made with setlocale(3C), as an example for 32-bit environment, the function looks for the locale shared object at /usr/lib/locale//.so.3. In this process of locating the locale shared object, the name given to the setlocale(3C) and the component of the path to the locale shared object must be identical byte by byte. If there is no requested locale shared object, i.e., the locale, found, then, the setlocale() will return NULL and the current locale, i.e., C locale in most of the case, will not be changed. (The same also applies to the LC_MESSAGES category directory.) This project slightly changes the current failure return mechanism briefly noted at the above such that if the locale is not found, before returning NULL, the setlocale(3C) will try to find out if the given locale name is an alias or not and if so what would be the matching canonical locale name being supported at Solaris. When there is a matching canonical locale name, then, the function will try to locate and load the locale if any. Details on this (including a simple normalization mechanism on the codeset part of the locale names during the matching process) are described in the NOTES section of the updated setlocale(3C) man page [2] and also in the subsection 1 of the DESCRIPTION section of the new man page, locale_alias(5) [2]. This additional checking will not overwrite or change the user's locale environment variable settings; it will just internally and transparently map a locale name alias into a canonical locale name, locate, and load the locale if any and applicable. Afterward, all internationalized APIs will work transparently as if the locale name supplied is the canonical locale name. A similar approach plus some additional steps will also take place in translated message retrieval functions: If the locale name given is a canonical locale name to obsoleted Solaris locale names by [3] and [4] and there is no associated translated message object or catalog in the system with the locale name, for a better backward compatibility, the messaging functions will additionally look for the message object or catalog using the obsoleted Solaris locale names as the additional locale names to check on against with. Also, as a part of locale name alias support mechanism, if the locale name given is an accepted and supported locale name alias to a canonical locale name by this project and there is no associated translated message object or catalog in the system with the locale name, the messaging functions will additionally look for its message object or catalog by using the canonical locale name. Details on these are described in the updated man pages, gettext(1), catopen(3C), gettext(3C), and environ(5) [2] and the new man page, locale_alias(5) [2]. These additional checkings are necessary to make our messaging functionality transparently work for obsoleted Solaris locales and also for the supported locale name aliases. The reason why the project team is explicitly updating the messaging function related man pages is due to that the interfaces are explicitly specifying the locale directories and locale names. No other internationalized interfaces appear requiring such explicit update on the man pages. The mapping tables shown at locale_alias(5) [2] are formulated from the data extracted from [3], [4], and some operating systems such as AIX 6.1, HP-UX 11.11, RHEL 5.4, Ubuntu 9.04, and the latest OpenSolaris/Solaris Nevada via some simple reverse engineering. They will be embedded into libc under read only data section. (We expect there will be no significant changes at the tables, if any, in the future.) Although this project does not change locale(1) utility, this project also update the NOTES section of locale(1) man page as shown at [2] to clarify on the "locale -a" output that locale aliases are supported only as aliases and will not be shown at the output. The scope of this project is within libc only and thus if there is any system utilities and/or libraries in this and other consolidations that individually reference and maintain locale names by themselves, to have a similar alias support, such utilities and/or libraries should undergo similar changes. (It appears there are not that many and significant cases of that.) INTERFACE STABILITY AND RELEASE BINDING This project imports no notable interfaces. This project exports: Interface Stability Note --------- --------- ---- gettext(1) Committed Updated utility as shown at [2] locale(1) man page Committed Updated man page as shown at [2] change only catopen(3C) Committed Updated API as shown at [2] gettext(3C) functions Committed Updated APIs as shown at [2] setlocale(3C) Committed Updated API as shown at [2] environ(5) Committed Updated NLSPATH as shown at [2] locale_alias(5) Committed New man page on mappings [2] This project asks for Micro/Patch release binding. REFERENCES [1] The Open Group, The Unix Internationalization Guide, Sep. 2003. http://www.opengroup.org/bookstore/catalog/g032.htm [2] New and updated man pages in flat text and corresponding diff files at the materials directory of the case: gettext.1, gettext.1.diff, locale.1, locale.1.diff, catopen.3c, catopen.3c.diff, gettext.3c, gettext.3c.diff, setlocale.3c, setlocale.3c.diff, environ.5, environ.5.diff, locale_alias.5 [3] PSARC/2009/342 EOF of @euro locales. [4] PSARC/2009/528 EOF of short form locales. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: G11N 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Fri Oct 30 21:28:14 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V4SDI9003652 for ; Fri, 30 Oct 2009 21:28:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9V4S75t010654 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 31 Oct 2009 12:28:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSD00L0332Y2W00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 30 Oct 2009 21:28:10 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSD00ILW32YKN40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 30 Oct 2009 21:28:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9V4SAdW013076 for ; Fri, 30 Oct 2009 21:28:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSD00H002QU8Y00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 30 Oct 2009 21:28:10 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSD003HO32XLO50@fe-sfbay-09.sun.com>; Fri, 30 Oct 2009 21:28:09 -0700 (PDT) Date: Fri, 30 Oct 2009 21:28:09 -0700 From: "Garrett D'Amore" Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <4AEBBCD9.7050508@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 8114 It looks like you're planning on baking the list of aliases into the libc binary itself? I'd really rather not do that. Would it be better to put the aliases in a separate file -- call it "locale_alias" to match your man page? -- Garrett Ienup Sung wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Locale name alias support at libc > 1.2. Name of Document Author/Supplier: > Author: Ienup Sung > 1.3 Date of This Document: > 30 October, 2009 > 4. Technical Description > > OVERVIEW > > When Solaris systems are newly introduced into a heterogeneous environment > dominated by other operating systems, say, an IBM shop or a HP-UX shop, due to > that the locale names being used at ours and other platforms such as AIX, > HP-UX, and various Linux distributions are slightly different in many cases, > even though we have compatible and acceptable locales at Solaris, existing > users' locale environment variable settings of such shops are not honored > causing an operational interoperability/compatibility issue especially in > accepting Solaris systems. > > As an example, while Solaris uses fr_FR.UTF-8 as the locale name for > French France UTF-8 locale, IBM AIX uses FR_FR and HP-UX 11.11 and RHEL 5.4 > use fr_FR.utf8. (It also appears that glibc based Linux distributions allow > some variations of the locale names in codeset part of locale name via > some kind of codeset name normalization mechanism hence accepting not only > fr_FR.UTF-8 and fr_FR.UTF8 but also fr_FR.utf8.) > > One way to resolve this interoperability/compatibility issue would be > creating and maintaining thousands of locale name related symbolic links at > our locale directories but that will be quite messy and very difficult to > maintain. > > Hence, this project proposes to have a transparent locale name alias support > mechanism at libc with embedded locale name mapping tables as outlined at > below to remedy the interoperability/compatibility issue and aid users > who want to migrate from other platforms to Solaris. > > > TECHNICAL DETAILS > > Currently, when a locale selection is made with setlocale(3C), as an example > for 32-bit environment, the function looks for the locale shared object at > /usr/lib/locale//.so.3. In this process of locating the locale > shared object, the name given to the setlocale(3C) and the > component of the path to the locale shared object must be identical byte by > byte. If there is no requested locale shared object, i.e., the locale, found, > then, the setlocale() will return NULL and the current locale, i.e., C locale > in most of the case, will not be changed. (The same also applies to > the LC_MESSAGES category directory.) > > This project slightly changes the current failure return mechanism briefly > noted at the above such that if the locale is not found, before returning > NULL, the setlocale(3C) will try to find out if the given locale name is > an alias or not and if so what would be the matching canonical locale name > being supported at Solaris. When there is a matching canonical locale name, > then, the function will try to locate and load the locale if any. Details on > this (including a simple normalization mechanism on the codeset part of > the locale names during the matching process) are described in the NOTES > section of the updated setlocale(3C) man page [2] and also in the subsection 1 > of the DESCRIPTION section of the new man page, locale_alias(5) [2]. > > This additional checking will not overwrite or change the user's locale > environment variable settings; it will just internally and transparently > map a locale name alias into a canonical locale name, locate, and load > the locale if any and applicable. Afterward, all internationalized APIs > will work transparently as if the locale name supplied is the canonical > locale name. > > A similar approach plus some additional steps will also take place in > translated message retrieval functions: > > If the locale name given is a canonical locale name to obsoleted Solaris > locale names by [3] and [4] and there is no associated translated message > object or catalog in the system with the locale name, for a better backward > compatibility, the messaging functions will additionally look for the message > object or catalog using the obsoleted Solaris locale names as the additional > locale names to check on against with. Also, as a part of locale name alias > support mechanism, if the locale name given is an accepted and supported > locale name alias to a canonical locale name by this project and there is > no associated translated message object or catalog in the system with > the locale name, the messaging functions will additionally look for its > message object or catalog by using the canonical locale name. Details on > these are described in the updated man pages, gettext(1), catopen(3C), > gettext(3C), and environ(5) [2] and the new man page, locale_alias(5) [2]. > > These additional checkings are necessary to make our messaging functionality > transparently work for obsoleted Solaris locales and also for the supported > locale name aliases. The reason why the project team is explicitly updating > the messaging function related man pages is due to that the interfaces are > explicitly specifying the locale directories and locale names. No other > internationalized interfaces appear requiring such explicit update on > the man pages. > > The mapping tables shown at locale_alias(5) [2] are formulated from the > data extracted from [3], [4], and some operating systems such as AIX 6.1, > HP-UX 11.11, RHEL 5.4, Ubuntu 9.04, and the latest OpenSolaris/Solaris Nevada > via some simple reverse engineering. They will be embedded into libc under > read only data section. (We expect there will be no significant changes at > the tables, if any, in the future.) > > Although this project does not change locale(1) utility, this project also > update the NOTES section of locale(1) man page as shown at [2] to clarify on > the "locale -a" output that locale aliases are supported only as aliases and > will not be shown at the output. > > The scope of this project is within libc only and thus if there is any system > utilities and/or libraries in this and other consolidations that individually > reference and maintain locale names by themselves, to have a similar alias > support, such utilities and/or libraries should undergo similar changes. > (It appears there are not that many and significant cases of that.) > > > INTERFACE STABILITY AND RELEASE BINDING > > This project imports no notable interfaces. This project exports: > > Interface Stability Note > --------- --------- ---- > gettext(1) Committed Updated utility as shown at [2] > locale(1) man page Committed Updated man page as shown at [2] > change only > catopen(3C) Committed Updated API as shown at [2] > gettext(3C) functions Committed Updated APIs as shown at [2] > setlocale(3C) Committed Updated API as shown at [2] > environ(5) Committed Updated NLSPATH as shown at [2] > locale_alias(5) Committed New man page on mappings [2] > > This project asks for Micro/Patch release binding. > > > REFERENCES > > [1] The Open Group, The Unix Internationalization Guide, Sep. 2003. > http://www.opengroup.org/bookstore/catalog/g032.htm > [2] New and updated man pages in flat text and corresponding diff files at > the materials directory of the case: > gettext.1, gettext.1.diff, > locale.1, locale.1.diff, > catopen.3c, catopen.3c.diff, > gettext.3c, gettext.3c.diff, > setlocale.3c, setlocale.3c.diff, > environ.5, environ.5.diff, > locale_alias.5 > [3] PSARC/2009/342 EOF of @euro locales. > [4] PSARC/2009/528 EOF of short form locales. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > G11N > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Vladimir.Marek@sun.com Mon Nov 2 08:35:03 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2GZ3bj015510 for ; Mon, 2 Nov 2009 08:35:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA2GZ2T5021044 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Nov 2009 08:35:03 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSH0070HQ2ETI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 08:35:02 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSH0001WQ2CU7A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 08:35:01 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA2GYxsq017339 for ; Mon, 02 Nov 2009 16:35:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSH00300PBJ6300@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 16:34:52 +0000 (GMT) Received: from pub ([unknown] [129.157.18.82]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSH00FTWQ221VB0@fe-emea-09.sun.com>; Mon, 02 Nov 2009 16:34:51 +0000 (GMT) Date: Mon, 02 Nov 2009 17:34:50 +0100 From: Vladimir Marek Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> Sender: Vladimir.Marek@sun.com To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Mail-followup-to: Ienup Sung , PSARC-ext@Sun.COM, i18n-discuss@opensolaris.org Message-id: <20091102163449.GC20252@pub> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> User-Agent: Mutt/1.5.19 (2009-05-30) Status: RO Content-Length: 6010 Hi, [...] > As an example, while Solaris uses fr_FR.UTF-8 as the locale name for > French France UTF-8 locale, IBM AIX uses FR_FR and HP-UX 11.11 and RHEL 5.4 > use fr_FR.utf8. (It also appears that glibc based Linux distributions allow > some variations of the locale names in codeset part of locale name via > some kind of codeset name normalization mechanism hence accepting not only > fr_FR.UTF-8 and fr_FR.UTF8 but also fr_FR.utf8.) > > One way to resolve this interoperability/compatibility issue would be > creating and maintaining thousands of locale name related symbolic links at > our locale directories but that will be quite messy and very difficult to > maintain. I just wonder, what's wrong (messy?) about thousands of symbolic links in directory? I might be horribly naive, but I thought that managing files (links) is quite easy task for any packaging system. Moreover the 'managing' will be most probably just adding the missing links, no deleting or renaming (exceptions proves the rule). The downsizes of such solution I see: a) unintuitive If my locale does not work and similar are installed (consulting locale -a), first I would look into locale directory to see what's there. Creating just another symlink is next logical step. b1) harder to manage If we have separate packages for each locale, the shared locale_alias would have to be dynamically modified with each package install and remove. b2) harder to manage if there is single locale_alias file, and user makes modifications, we have to merge his change with our own patches (or how it is called these days). Creating symlink does not interfere with other packages. c) slow If user has LC_ALL=blah, then each subsequent setlocale(3C) has to go through the locale_alias and compare thousands of lines to blah. Setlocale is frequently called command ... (You could cache this blah=cs_CZ somewhere. But then there is need for tools to purge this cache and user has to find out how to do it when he changes the locale_alias). > Hence, this project proposes to have a transparent locale name alias support > mechanism at libc with embedded locale name mapping tables as outlined at > below to remedy the interoperability/compatibility issue and aid users > who want to migrate from other platforms to Solaris. Linux uses locale.alias (Debian has /etc/locale.alias and /usr/X11R6/lib/X11/locale/locale.alias for example). To aid Linux users, it might be good idea to create locale.alias(4) man page. > TECHNICAL DETAILS > > Currently, when a locale selection is made with setlocale(3C), as an example > for 32-bit environment, the function looks for the locale shared object at > /usr/lib/locale//.so.3. In this process of locating the locale > shared object, the name given to the setlocale(3C) and the > component of the path to the locale shared object must be identical byte by > byte. That is problem for symlinks. Still would not it be easier to relax this scheme a bit (file locale.so.3 would work for all locales [pardon my naivity again ...]). [...] [ ... LC_MESSAGES ] > If the locale name given is a canonical locale name to obsoleted Solaris > locale names by [3] and [4] and there is no associated translated message > object or catalog in the system with the locale name, for a better backward > compatibility, the messaging functions will additionally look for the message > object or catalog using the obsoleted Solaris locale names as the additional > locale names to check on against with. Also, as a part of locale name alias > support mechanism, if the locale name given is an accepted and supported > locale name alias to a canonical locale name by this project and there is > no associated translated message object or catalog in the system with > the locale name, the messaging functions will additionally look for its > message object or catalog by using the canonical locale name. Details on > these are described in the updated man pages, gettext(1), catopen(3C), > gettext(3C), and environ(5) [2] and the new man page, locale_alias(5) [2]. > > These additional checkings are necessary to make our messaging functionality > transparently work for obsoleted Solaris locales and also for the supported > locale name aliases. The reason why the project team is explicitly updating > the messaging function related man pages is due to that the interfaces are > explicitly specifying the locale directories and locale names. No other > internationalized interfaces appear requiring such explicit update on > the man pages. > > The mapping tables shown at locale_alias(5) [2] are formulated from the > data extracted from [3], [4], and some operating systems such as AIX 6.1, > HP-UX 11.11, RHEL 5.4, Ubuntu 9.04, and the latest OpenSolaris/Solaris Nevada > via some simple reverse engineering. They will be embedded into libc under > read only data section. (We expect there will be no significant changes at > the tables, if any, in the future.) Oh, this is not file, but rather ELF section? I don't see the aid for the user if he has to file escalation (pay support first) and wait some time to get updated packages from upstream, just to make his cs_CZ.UtF-8 work? > Although this project does not change locale(1) utility, this project also > update the NOTES section of locale(1) man page as shown at [2] to clarify on > the "locale -a" output that locale aliases are supported only as aliases and > will not be shown at the output. Just out of interest, what is the difference between canonical locale name, and 'additional locale name'? Why do we have to keep them separated? We would not need lawyer-like documentation like http://sac.sfbay/PSARC/2009/594/materials/setlocale.3c.diff Maybe I just don't see the problem. Customer takes his script form HP-UX, and suddenly it's output is not in French, but rather in English. How exactly will help him this quite complex change? Thank you for your patience with me -- Vlad From Ienup.Sung@sun.com Mon Nov 2 09:02:05 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2H24UX016299 for ; Mon, 2 Nov 2009 09:02:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA2H23tN054526 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Nov 2009 10:02:04 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSH00B01RBFZP00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 10:02:03 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSH007OBRBEDU40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 10:02:02 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA2H2283002682 for ; Mon, 02 Nov 2009 09:02:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSH00D00QUAPY00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:02:02 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.243.220]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSH00EX3RARACA0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:01:48 -0800 (PST) Date: Mon, 02 Nov 2009 08:59:56 -0800 From: Ienup Sung Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <4AEBBCD9.7050508@sun.com> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <4AEF100C.4020600@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <4AEBBCD9.7050508@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 846 Garrett D'Amore wrote at 10/30/09 21:28: > It looks like you're planning on baking the list of aliases into the > libc binary itself? I'd really rather not do that. Would it be better > to put the aliases in a separate file -- call it "locale_alias" to match > your man page? > > -- Garrett You're correct that I hope to bake the list of aliases into the libc since we don't expect that the list will change in the future. (The chance of it being updated significantly would be very slim.) Considering that, I really don't think that we need to have the list externalize for future extension at this point. That's also the reason why the locale_alias(5) man page is at section 5 not section 4 since the man page is to merely give appropriate information to users and be the source reference for the changes at other man pages. Ienup From Nicolas.Williams@sun.com Mon Nov 2 09:04:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2H4D8P016322 for ; Mon, 2 Nov 2009 09:04:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA2H4CxQ056179 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Nov 2009 10:04:13 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSH0070JRF0J400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:04:12 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSH00756RF0IG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:04:12 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA2Gqg0H006004; Mon, 02 Nov 2009 10:52:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA2GqgZ1006003; Mon, 02 Nov 2009 10:52:42 -0600 (CST) Date: Mon, 02 Nov 2009 10:52:42 -0600 From: Nicolas Williams Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <20091102163449.GC20252@pub> To: Ienup Sung , PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20091102165242.GV1105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <20091102163449.GC20252@pub> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2522 On Mon, Nov 02, 2009 at 05:34:50PM +0100, Vladimir Marek wrote: > Linux uses locale.alias (Debian has /etc/locale.alias and > /usr/X11R6/lib/X11/locale/locale.alias for example). To aid Linux users, > it might be good idea to create locale.alias(4) man page. > > > > The mapping tables shown at locale_alias(5) [2] are formulated from the > > data extracted from [3], [4], and some operating systems such as AIX 6.1, > > HP-UX 11.11, RHEL 5.4, Ubuntu 9.04, and the latest OpenSolaris/Solaris Nevada > > via some simple reverse engineering. They will be embedded into libc under > > read only data section. (We expect there will be no significant changes at > > the tables, if any, in the future.) > > Oh, this is not file, but rather ELF section? I don't see the aid for > the user if he has to file escalation (pay support first) and wait some > time to get updated packages from upstream, just to make his cs_CZ.UtF-8 > work? If Linux makes locale aliases configurable, then we should consider doing the same. Locale names/aliases are best not picked by users, not randomly anyways, but given the history here, I think letting users configure locale aliases is fine. We should also consider hardcoding common alias canonicalization algorightms such as "fold up the case of the codeset name component of the locale". It's fine, IMO, to "compile" a locale alias DB so that a quick index operation can be used (whether an ELF symbol table, a directory, or a sorted list of fixed-sized entries). Making the user run some command to update the locale alias DB seems fine. > > Although this project does not change locale(1) utility, this project also > > update the NOTES section of locale(1) man page as shown at [2] to clarify on > > the "locale -a" output that locale aliases are supported only as aliases and > > will not be shown at the output. > > Just out of interest, what is the difference between canonical locale > name, and 'additional locale name'? Why do we have to keep them > separated? We would not need lawyer-like documentation like > http://sac.sfbay/PSARC/2009/594/materials/setlocale.3c.diff If aliases are configured, then locale(1) should have an option to list them. If aliases are algorithmically determined then there may not be a way to list them all, but a locale(1) option to determine whether a given locale name is valid and what its canonical form is, would be nice. Presumably running "LC_ALL= locale" would show the canonicalized locale names in its output. Nico -- From Alan.Coopersmith@sun.com Mon Nov 2 09:10:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2HAKlS016513 for ; Mon, 2 Nov 2009 09:10:21 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA2H9vqR017378 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Nov 2009 01:10:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSH00901RP7TS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:10:19 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSH000T7RP7UDD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:10:19 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA2HAJEW003601 for ; Mon, 02 Nov 2009 09:10:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSH00B00QPU3F00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:10:19 -0800 (PST) Received: from [129.145.155.53] ([unknown] [129.145.155.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSH00E0QROKACE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 09:09:56 -0800 (PST) Date: Mon, 02 Nov 2009 09:09:56 -0800 From: Alan Coopersmith Subject: Re: [i18n-discuss] Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <4AEF100C.4020600@sun.com> Sender: Alan.Coopersmith@sun.com To: Ienup.Sung@sun.com Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <4AEF1264.7070404@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <4AEBBCD9.7050508@sun.com> <4AEF100C.4020600@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090720) Status: RO Content-Length: 1116 Ienup Sung wrote: > Garrett D'Amore wrote at 10/30/09 21:28: >> It looks like you're planning on baking the list of aliases into the >> libc binary itself? I'd really rather not do that. Would it be >> better to put the aliases in a separate file -- call it "locale_alias" >> to match your man page? >> >> -- Garrett > > You're correct that I hope to bake the list of aliases into > the libc since we don't expect that the list will change in the future. > (The chance of it being updated significantly would be very slim.) The locale.alias list that libX11 uses is updated almost every libX11 release due to changes in various OS'es/distros, and the inevitable political upheavals. (Try as we might, we haven't convinced the world governments to make the names and boundaries of nations into a stable interface, so have to deal with things such as the breakup and renaming of the Balkan states.) The scm history for it: http://cgit.freedesktop.org/xorg/lib/libX11/log/nls/locale.alias.pre -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Ienup.Sung@sun.com Mon Nov 2 12:42:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2KgFLB021596 for ; Mon, 2 Nov 2009 12:42:15 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA2KgEFa058351 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Nov 2009 13:42:14 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSI00B011ID7700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 02 Nov 2009 13:42:13 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSI0053T1IC0J40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 02 Nov 2009 13:42:12 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA2KgCtW015947 for ; Mon, 02 Nov 2009 12:42:12 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSI00D001GDUZ00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 02 Nov 2009 12:42:12 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.243.220]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSI00LL61HLWYB0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 02 Nov 2009 12:41:46 -0800 (PST) Date: Mon, 02 Nov 2009 12:40:01 -0800 From: Ienup Sung Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <20091102163449.GC20252@pub> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <4AEF43A1.4020706@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <20091102163449.GC20252@pub> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 12107 Hello Vladimir, There are a few things that I hope to write in front portion of this email since I believe they deserve some better visibility. I also inlined my answers in the email at below for all the questions you have. Please be noted first that this alias support mechanism isn't providing external files for the two sets of the alias mappings as clearly indicated by the section 5 in the locale_alias(5) man page name and the spec. Second, you mention how this will help a customer who took his script from a HP-UX box to Solaris box and suddenly its output isn't in French but in English. There are various reasons why the output could be in English. I am sure you understand that I'm not providing a panacea for all possible kinds of problems involved with that question since providing the panacea for such unknown problems is simply not really and practically possible. However, if the script is a properly internationalized one that uses publically available interfaces and assumes and uses HP-UX locale names in it, then, the script will work fine in the Solaris box as if the HP-UX locale names are supported (as long as the Solaris box has corresponding canonical locale and localization in it). Better examples for the project are something like the following: 1. In an IBM shop, customers have "setenv LANG CS_CZ" for Czech Czech Republic UTF-8 locale environment, say, in their ~/.cshrc file. They now have a Solaris box and did "ssh" to the Solaris box which will then forward the CS_CZ locale environment variable settings to the Solaris box. Without the locale alias support, you will see C locale and English messages even though the Solaris box has cs_CZ.UTF-8 locale. With the locale alias support, on the other hand, you will see Czech messages as if CS_CZ locale is supported in Solaris even though the guts are actually coming from the cs_CZ.UTF-8 locales. 2. In an HP/Linux shop, customers have "setenv LANG ja_JP.SJIS" for Japanese Japan Shift_JIS locale environment in their ~/.cshrc file which is accessed through NFS home directory. Now they have Solaris boxes and if they sit in front of a Solaris workstation and log in to it, then, without the locale alias support, their locale environment settings at ~/.cshrc will not be honored and they will fallback to C locale with English messages. With the locale alias support, on the other hand, they will see Japanese locale and messages since the locale alias support will map the ja_JP.SJIS internally to ja_JP.PCK at Solaris boxes. We G11N consider this project important for our business and user conveniences and help people to migrate to ours. All others, I inlined in the email at below the answers. Ienup Vladimir Marek wrote at 11/02/09 08:34: > I just wonder, what's wrong (messy?) about thousands of symbolic links > in directory? I might be horribly naive, but I thought that managing > files (links) is quite easy task for any packaging system. Moreover the > 'managing' will be most probably just adding the missing links, no > deleting or renaming (exceptions proves the rule). As an example, soon enough, we will have to update the locale shared objects, once again, to incorporate the new Austin standard revision and at that time, it is inevitable for us to up the shared objects' version from the current .so.3 and methods_.so.3 to, say, *.so.4. That means we will not only have to update the canonical locales but also have to ensure that all of those so many thousand symbolic links are also correctly changed if we were to support the aliases with symlinks. (I believe the number of symlinks will be somewhere between a half million to a bit more than 1 million.) That's going to be and clearly a maintenance hazard and overhead and I don't think we have enough bandwidth and resource to handle that kind of changes, do you? > The downsizes of such solution I see: > > a) unintuitive > If my locale does not work and similar are installed (consulting locale > -a), first I would look into locale directory to see what's there. > Creating just another symlink is next logical step. It is precisely the reason why there is locale_alias(5) man page and locale(1) man page update and so on so that we document and give info to people instead of let people to look into system directories which isn't really an official interface to regular users for that matter. (I'm a geek for sure to know the details and will look into system directories and what not since I was responsible for LC_COLLATE category in SunOS and wrote the guts when we re-architectured it to be codeset independent several years ago but I don't plan to ask people to look at /usr/lib/locale/ directory for them to know the available locales at the current system; that's the last resort thing that I would recommend regular people to do.) Re the "creating just another symlinks", if you wish, you (i.e., customers) can always do that even after the project integration. > b1) harder to manage > If we have separate packages for each locale, the shared locale_alias > would have to be dynamically modified with each package install and > remove. The locale_alias isn't a file and will not be. It is a section 5 man page merely to give miscellaneous information and in this case locale alias details including the lists of the supported locale aliases. Hence there is no change from packaging perspective. > b2) harder to manage > if there is single locale_alias file, and user makes modifications, we > have to merge his change with our own patches (or how it is called > these days). Creating symlink does not interfere with other packages. Again, no, there isn't locale_alias file as I explicitly mentioned about the tables and details at the spec and also locale_alias(5) man page. > c) slow > If user has LC_ALL=blah, then each subsequent setlocale(3C) has to go > through the locale_alias and compare thousands of lines to blah. > Setlocale is frequently called command ... (You could cache this > blah=cs_CZ somewhere. But then there is need for tools to purge this > cache and user has to find out how to do it when he changes the > locale_alias). There is no change what so ever if you're using canonical locale names as you're supposed to do so since this alias checking is the last resort step within the setlocale(3C) and even with, say LC_ALL=blah like erroneous settings, the search to find if it is a supported alias will be extremely fast with only a few comparisons of characters in locale names with a modified indexed trie search data structure. Also, to be more precise on what's on the stake and matters, this is about whether to fail for acceptable locale aliases and fall back to C locale *or* to have a few comparisons of characters and find out if it is a supported locale alias or not (and only when the locale name supplied isn't supported as it is) and, if so, support the locale alias to have a better compatibility with other competing platforms *not* on the performance degradation on erroneous locale setting cases. >> Hence, this project proposes to have a transparent locale name alias support >> mechanism at libc with embedded locale name mapping tables as outlined at >> below to remedy the interoperability/compatibility issue and aid users >> who want to migrate from other platforms to Solaris. > > Linux uses locale.alias (Debian has /etc/locale.alias and > /usr/X11R6/lib/X11/locale/locale.alias for example). To aid Linux users, > it might be good idea to create locale.alias(4) man page. We already have X11 locale.alias file and we have been having it for almost two decades now and so that's not a topic to discuss. The Debian /etc/locale.alias is a way to have an alias support. I don't think that is really necessary for us as other Linux distros are not supporting it and considering that we will have locale_alias embedded into libc. I'll also elaborate on this with replies to Nicolas's and Alan's emails. >> TECHNICAL DETAILS >> >> Currently, when a locale selection is made with setlocale(3C), as an example >> for 32-bit environment, the function looks for the locale shared object at >> /usr/lib/locale//.so.3. In this process of locating the locale >> shared object, the name given to the setlocale(3C) and the >> component of the path to the locale shared object must be identical byte by >> byte. > > That is problem for symlinks. Still would not it be easier to relax this > scheme a bit (file locale.so.3 would work for all locales [pardon my > naivity again ...]). Please elaborate what did you mean by the above, "file locale.so.3 would work for all locales" and also "That is problem of symlinks." The reason why I'm asking this is that it appears that you're proposing a single locale shared object for all locales?? >> The mapping tables shown at locale_alias(5) [2] are formulated from the >> data extracted from [3], [4], and some operating systems such as AIX 6.1, >> HP-UX 11.11, RHEL 5.4, Ubuntu 9.04, and the latest OpenSolaris/Solaris Nevada >> via some simple reverse engineering. They will be embedded into libc under >> read only data section. (We expect there will be no significant changes at >> the tables, if any, in the future.) > > Oh, this is not file, but rather ELF section? I don't see the aid for > the user if he has to file escalation (pay support first) and wait some > time to get updated packages from upstream, just to make his cs_CZ.UtF-8 > work? I think you thought locale_alias(5) is a file that this project will supply? And then as you are reading the spec, now you found that it isn't? Please elaborate if that's case re locale_alias(5). Re the cs_CZ.UtF-8 locale name, as I specified in the locale_alias(5) man page, there is a codeset part normalization in this enhancement project and thus cs_CZ.UtF-8, cs_CZ.UTF8, cs_CZ.utf8, cs_CZ.utf-8, and so on will all be accepted as cs_CZ.UTF-8 aliases as a by product of the codeset part normalization. Please read locale_alias(5) man page. >> Although this project does not change locale(1) utility, this project also >> update the NOTES section of locale(1) man page as shown at [2] to clarify on >> the "locale -a" output that locale aliases are supported only as aliases and >> will not be shown at the output. > > > Just out of interest, what is the difference between canonical locale > name, and 'additional locale name'? Why do we have to keep them > separated? We would not need lawyer-like documentation like > http://sac.sfbay/PSARC/2009/594/materials/setlocale.3c.diff You may not need explicit specification but such specification is needed to make our features clearly documented and described. Under documenting, ambiguous documentation, or lack of it should be considered harmful not the other way. I also think that what I proposed are not over-specifying things. The canonical locale names are, literally, locale names of established principles. The locale name aliases are, literally, aliases to canonical locale names. Re the "additional locale names", as described in the catopen(3C) and gettext(1), they literally refer to locale names that the gettext(1) and so on are going to additionally check on to find its message catalog: If lang specified is a canonical locale name to obsoleted Solaris | locale names as described in locale_alias(5) and the above mentioned | ordinary locations with lang do not yield a message object, for | a better backward compatibility, gettext additionally looks for | its message object using the obsoleted Solaris locale names as | the additional locale names to check on with in place of lang. | What part of it do you find not clear? > Maybe I just don't see the problem. Customer takes his script form > HP-UX, and suddenly it's output is not in French, but rather in English. > How exactly will help him this quite complex change? Please see the answer at the beginning of this email. > > > Thank you for your patience with me > From Ienup.Sung@Sun.COM Mon Nov 2 13:00:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2L0EgP022135 for ; Mon, 2 Nov 2009 13:00:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA2L0DoS004717 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Nov 2009 14:00:13 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSI00E012CD6F00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:00:13 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSI007KJ2CDXB90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:00:13 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA2L0D7D018258 for ; Mon, 02 Nov 2009 13:00:13 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSI0020029WBF00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:00:13 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.243.220]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSI004012CCIM00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:00:13 -0800 (PST) Date: Mon, 02 Nov 2009 12:58:28 -0800 From: Ienup Sung Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <20091102165242.GV1105@Sun.COM> Sender: Ienup.Sung@Sun.COM To: PSARC-ext@Sun.COM Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@Sun.COM Message-id: <4AEF47F4.1070105@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <20091102163449.GC20252@pub> <20091102165242.GV1105@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 2217 Nicolas Williams wrote at 11/02/09 08:52: > If Linux makes locale aliases configurable, then we should consider > doing the same. Locale names/aliases are best not picked by users, not > randomly anyways, but given the history here, I think letting users > configure locale aliases is fine. We should also consider hardcoding > common alias canonicalization algorightms such as "fold up the case of > the codeset name component of the locale". > > It's fine, IMO, to "compile" a locale alias DB so that a quick index > operation can be used (whether an ELF symbol table, a directory, or a > sorted list of fixed-sized entries). Making the user run some command > to update the locale alias DB seems fine. I believe that the /etc/locale.alias specific to Debian distribution is not user configurable per se or there are tools being provided for user customization. If the alias mappings are going to be frequently updated then we might need to have an external file or two but when the update of the alias mappings are not that frequent, having mmap()'ng and optional parsing of the tables appear not so ideal. Furthermore, we do already have plenty of mappings with the current locale alias mappings shown at the locale_alias(5) plus codeset part normalization as described in the same man page that will last quite long time for us. If there will be a need to update the alias mappings one way or another, I think it will be much easier and economic for us to do the update as a minor bug fix level change of the mappings. > If aliases are configured, then locale(1) should have an option to list > them. If aliases are algorithmically determined then there may not be a > way to list them all, but a locale(1) option to determine whether a > given locale name is valid and what its canonical form is, would be > nice. Presumably running "LC_ALL= locale" would show the > canonicalized locale names in its output. It is part algorithmically determined with this project as specified in the locale_alias(5) man page since that's the way it appears glibc understands locale name aliases. At this point, the project team does not propose the have the locale alias mappings user customizable. Ienup From Ienup.Sung@sun.com Mon Nov 2 13:09:15 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA2L9ElY022243 for ; Mon, 2 Nov 2009 13:09:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA2L8xmb028284 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Nov 2009 05:09:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSI002072RCBU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:09:12 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSI00BHU2RBNAE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:09:12 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA2L9BcX019245 for ; Mon, 02 Nov 2009 13:09:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSI00I002GPND00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:09:11 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.243.220]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSI00I7X2RAX120@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 13:09:10 -0800 (PST) Date: Mon, 02 Nov 2009 13:07:26 -0800 From: Ienup Sung Subject: Re: [i18n-discuss] Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <4AEF1264.7070404@sun.com> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <4AEF4A0E.2090807@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <4AEBBCD9.7050508@sun.com> <4AEF100C.4020600@sun.com> <4AEF1264.7070404@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 1617 Alan Coopersmith wrote at 11/02/09 09:09: > The locale.alias list that libX11 uses is updated almost every libX11 > release due to changes in various OS'es/distros, and the inevitable > political upheavals. (Try as we might, we haven't convinced the > world governments to make the names and boundaries of nations into > a stable interface, so have to deal with things such as the breakup > and renaming of the Balkan states.) > > The scm history for it: > http://cgit.freedesktop.org/xorg/lib/libX11/log/nls/locale.alias.pre We have been delivering locale.alias file for almost two decades with Solaris and I was clearly involved in the file since one time I owned the file among other things. There is no denying on that, due to geo political changes and what not, there is no way that all the locale names will be static forever. However, the mappings that we already have as shown in the locale_alias(5) plus codeset part normalization, again, described in the same man page, I think that a pretty good coverage is already provided with the current project proposal in terms of locale aliases as far as we are concerned and it will last quite long time for us. And so unless there is a specific and explicit requirement, the project team doesn't hope to additionally design and implement user customizable locale alias support mechanism with this project. Later, when there is a clear revenue related or community requirement that we cannot handle without the user customizable locale alias mappings, then, we will at that time, do another project extending on top of the currently proposed project. Ienup From gdamore@sun.com Mon Nov 2 19:35:38 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA33ZbsZ000431 for ; Mon, 2 Nov 2009 19:35:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA33ZWXg021582 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Nov 2009 11:35:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSI00901KNBOT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 20:35:35 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSI0068GKNAEHE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 20:35:34 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA33ZY7J018804 for ; Mon, 02 Nov 2009 19:35:34 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSI00J00KAQS600@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 19:35:34 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSI00M3VKN9J200@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Nov 2009 19:35:34 -0800 (PST) Date: Mon, 02 Nov 2009 19:35:33 -0800 From: "Garrett D'Amore" Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <4AEF47F4.1070105@sun.com> Sender: garrett.damore@sun.com To: Ienup.Sung@sun.com Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <4AEFA505.6070808@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <20091102163449.GC20252@pub> <20091102165242.GV1105@Sun.COM> <4AEF47F4.1070105@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 2578 Ienup Sung wrote: > Nicolas Williams wrote at 11/02/09 08:52: >> If Linux makes locale aliases configurable, then we should consider >> doing the same. Locale names/aliases are best not picked by users, not >> randomly anyways, but given the history here, I think letting users >> configure locale aliases is fine. We should also consider hardcoding >> common alias canonicalization algorightms such as "fold up the case of >> the codeset name component of the locale". >> >> It's fine, IMO, to "compile" a locale alias DB so that a quick index >> operation can be used (whether an ELF symbol table, a directory, or a >> sorted list of fixed-sized entries). Making the user run some command >> to update the locale alias DB seems fine. > > I believe that the /etc/locale.alias specific to Debian distribution is > not user configurable per se or there are tools being provided for user > customization. > > If the alias mappings are going to be frequently updated then we might > need > to have an external file or two but when the update of the alias > mappings are > not that frequent, having mmap()'ng and optional parsing of the tables > appear not so ideal. > > Furthermore, we do already have plenty of mappings with the current > locale > alias mappings shown at the locale_alias(5) plus codeset part > normalization > as described in the same man page that will last quite long time for us. > If there will be a need to update the alias mappings one way or another, > I think it will be much easier and economic for us to do the update as > a minor bug fix level change of the mappings. > > >> If aliases are configured, then locale(1) should have an option to list >> them. If aliases are algorithmically determined then there may not be a >> way to list them all, but a locale(1) option to determine whether a >> given locale name is valid and what its canonical form is, would be >> nice. Presumably running "LC_ALL= locale" would show the >> canonicalized locale names in its output. > > It is part algorithmically determined with this project as specified in > the locale_alias(5) man page since that's the way it appears glibc > understands > locale name aliases. > > At this point, the project team does not propose the have the locale > alias mappings user customizable. Personally, I think that's a mistake, but I also recognize that project team has thought about this (and particularly the performance implications from opening and parsing a file), and I'm satisfied enough that I'll give this project my +1. - Garrett > > Ienup From Ienup.Sung@sun.com Wed Nov 4 10:22:25 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA4IMOOu009108 for ; Wed, 4 Nov 2009 10:22:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA4IMI9A007748 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Nov 2009 10:22:24 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSL00K57KDBSR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 11:22:23 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSL00E4JKCPNTF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 11:22:02 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA4IM1ku001265 for ; Wed, 04 Nov 2009 10:22:01 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSL00700K77O000@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 10:22:01 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.226.202]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSL009HMKCOZ200@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 10:22:00 -0800 (PST) Date: Wed, 04 Nov 2009 10:20:13 -0800 From: Ienup Sung Subject: Re: Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009] In-reply-to: <4AEFA505.6070808@sun.com> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <4AF1C5DD.9020800@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910310040.n9V0etcg027915@sac.sfbay.sun.com> <20091102163449.GC20252@pub> <20091102165242.GV1105@Sun.COM> <4AEF47F4.1070105@sun.com> <4AEFA505.6070808@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 67 This case was approved during today's PSARC review meeting. Ienup