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