On 7 May 2010 07:14, Wendy Lin <[email protected]> wrote: > Glenn, Olga, I would be very grateful if one of you could fix this for > the next ksh93t release or make a patch available. Working, built in > localization support in ksh93 would be a great benefit. > > On 3 May 2010 22:05, Glenn Fowler <[email protected]> wrote: >> >> Olga, thanks for looking into this and provding a link to Finbarr's blog >> sometimes the todo list is too long to track down and reproduce every problem >> >> there were a few problems that were bugs in libast: >> >> * $set==3 (ast) vs $set==1 (default) mismatches noted by Finbarr >> >> this is not necessarily a bug, but a strict ast convention that ast >> commands and scripts only look for messages in $set==3; this broke the >> principle of least surprise so ... >> >> this was fixed by translate() first checking for $set==3 and then $set==1 >> >> this allows ast messages ($set==3) to be included in non-ast message files >> but also allows the "default" $set==1 to be found in files that do not >> have a $set==3 message set >> >> * an underlying problem where ast may recognize a locale that the >> native setlocale()+catopen() do not >> >> in particular ast with ast-locale installed recognizes "fr" as a valid >> locale even though the native setlocale() requires territory qualification >> (e.g. "fr_FR") >> >> this was fixed by changing the ast local locale vs native standard locale >> logic >> >> the reason for the locale vs native distinction is that ast provides "local" >> locales on systems that may not otherwise support that locale; e.g., on a >> system >> that does not have the "fr_FR" locale installed you can still get >> ast-specific >> "fr" locale message translation from the catalogs in the ast-locale package >> >> ast also provides a "debug" local locale for debugging locale settings and >> message translation; running Finbarr's demo with LC_ALL=debug produces >> >> ksh93 message translation example >> (demo,3,1) >> (demo,3,2) >> (demo,3,3)(debug,demo,libshell,No Translation available) >> >> (demo,3,1) means message 1 in set 3 in the demo catalog; 3 is the lookup >> set, >> if not found then set 1 will be used per the fix above >> >> (debug,demo,libshell,No Translation available) is for messages that are not >> in the C locale catalogs: search the demo catalog first, then the libshell >> catalog, >> for the message "No Translation available" >> >> * some other bugs were fixed to allow intermingling of standard catgen(1) and >> ast msggen(1) compiled catalogs (these are the file types that catopen() >> must find) >> >> the reason for msggen(1) is the msggen(1) output is portable to all machine >> architectures >> this is how one ast-locale package can work on all hosttypes; similar >> guarantees >> cannot be made for catgen(1) output from different hosttypes >> >> the final misconception (and this is a results of ast documentation and >> coding bugs) >> in Finbarr's example and patch is the locations where ast looks for message >> catalogs >> >> in ast just about every command-related data file lookup is done via the ast >> pathpath() >> pathpath() lookups use only the PATH environment variable to search for >> related files >> e.g., >> ../lib/file/magic for the file(1) magic file >> ../lib/<plugin-class>/<plugin-shared-library> for runtime plugins >> the idea being, if you have the PATH properly set up to find the std and >> your own ast >> commands/scripts, then the related file lookups will work >> >> the message catalog search order is (using NLSPATH notation): >> getenv("NLSPATH") >> pathpath("share/lib/locale/%l/%C/%N") >> pathpath("share/locale/%l/%C/%N") >> pathpath("lib/locale/%l/%C/%N") >> >> so to package a script susbsystem using ksh93 (with the libast fixes >> mentioned above) >> put scripts in $PACKAGEROOT/bin >> put catgen(1) or msggen(1) catalogs in >> $PACKAGEROOT/share/lib/locale/%l/LC_MESSAGES/<script-name> >> (or share/locale/... or lib/locale/...) >> put $PACKAGEROOT/bin in PATH >> set LC_* to a supported locale >> >> if you use catgen(1) then you may have to provide os/architecture specific >> catalogs in your package distribution; msggen(1) should work on all >> os/architectures >> >> On Mon, 3 May 2010 02:14:50 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= >> wrote: >>> David, the problem is the name of the catalog. Instead of using the >>> script name it always uses 'libshell' as the catalog name. >>> I try to make a patch soon. >> >>> Olga >> >>> On Wed, Aug 12, 2009 at 4:44 PM, David Korn <[email protected]> wrote: >>> > cc: [email protected] >>> > Subject: Re: Re: [ast-developers] Seeking help with $"string", ksh -D, >>> > gencat and NLSPATH >>> > -------- >>> > >>> >> On 06/07/2009, Wendy Lin <[email protected]> wrote: >>> >> > On 22/05/2009, Finnbarr Murphy <[email protected]> wrote: >>> >> > > In short, as far as I can see, ksh93 does not appear to support >>> >> > localized >>> >> > > message strings at present. >>> >> > >>> >> > >>> >> > Can this be fixed for the next release, please? >>> > >>> >> After reading your blog at >>> >> http://blog.fpmurphy.com/2009/05/ksh93-message-localization.html I >>> >> feel very disappointed about ksh. >>> >> If bash 4.0 would support fp math we would immediately migrate to it >>> >> because it has the message localisation working. >>> >> >>> > >>> > >>> > ksh93 does support localized messages strings in scripts. >>> > >>> > Any string within a script that needs to be localized has to be >>> > written as >>> > $"string" >>> > In the C or POSIX locale this will be treated as "string". >>> > >>> > If you run >>> > ksh -D script >>> > it will generate the list of strings that need localization. >>> > >>> > These can be put into a catalog for the C local. >>> > >>> > The catalogs for each locale can be created. >> >> _______________________________________________ >> ast-developers mailing list >> [email protected] >> https://mailman.research.att.com/mailman/listinfo/ast-developers
Glenn, Olga, could you make a patch or a new alpha, beta or gamma release which fixes this bug? I *beg* you to fix this as soon as humanly possible. Wendy _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
