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 > -- Wendy _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
