On Tue, 18 May 2010 23:17:16 -0400 Finnbarr Murphy wrote:
> Before Glenn finalizes updating message localization support in libast=20
> we
> should come to some consensus on how we expect this support to work.=20
the "finalization" will be for a beta release
so it won't be cast in stone
nothing changed in the ast vision of doing message catalogs
its bug fixes in the implementation
(granted thats a distiction lost to an external observer)
> As far as I can tell (correct me if I am wrong) there never really has=20
> been
> a real discussion on this list about this issue.
> As I see it there are three scenarios:
> - Support for localization of messages in compiled applications
> which use AST libraries.
> - Support for localization of ksh93 internal messages.
> - Support for localization of messages in ksh93 scripts.
> I believe that the third scenario is the one that is of current interest
> to
> myself and Wendy.
> Besides the approach taken to message localization by ksh93 there are=20
> a number of other approaches to handing shell script message=20
> localization and I will briefly describe them as some people may not be
> aware of them.
> 1. The catgets methodology as used in CDE's dtksh. It uses NLS message=20
> catalogs. Here is a simple example of how it works.
> # open message catalog
> catopen CAT_ID "myCatalog.cat"
> # get message 14 from set 1
> catgets TEMP_STRING $CAT_ID 1 14 "Please check printer"
> # and output the message
> echo "$TEMP_STRING"
> # Close the message catalog=2C when no longer needed
> catclose $CAT_ID
> Tru64 UNIX used a similar approach=2C i.e. dspmsg(1) as does AIX.
there's nothing preventing ast users from doing this
but this method will not be championed by ast
ast C code uses the libast error(3) function which handles all translation
including libast optget(3) long option and --man documentation
> 2. Bash uses gettext together with PO message catalogs whose layout=20
> is totally different from NLS message catalogs. The following is a
> simplified example of the layout a PO file.
> white-space
> # translator-comments
> #. extracted-comments
> #: reference...
> #=2C flag...
> #| msgid previous-untranslated-string
> msgid1 untranslated-string
> msgstr1 translated-string
> ......
> msgidN untranslated-string
> msgstrN translated-string
ast and gettext use similar approaches
in that the C locale string is used as a lookup key for the translations
internally ast intercepts catgets(3) and looks in the ast catalogs first
and then in the catgets catalogs using the native implementation
> So what do I want of ksh93 as far as message localization is concerned?
> - Understands and honors the $"..." syntax (Already does) =20
> - Understands and honors the current locale environment as defined
> by IEEE Std 1003.1-2008 (Already does)
> - Honors all specified message sets - not just set 3. (Recently=20
> fixed)
> - Uses NLS message catalogs generated by the platform gencat utility.
> This makes production of message catalogs much easier and enables
> message catalog translators to work with existing toolsets.
this was the original intent and works with the to be published fixes
if gnu PO message catalogs are not hit by libc catgets(3) then PO
gettext(3) lookup can be added in the _ast_catgets() intercept without
changing any ast apis or user code
does glibc catgets(3) access PO message catalogs?
> - An additional message catalog search path ($PWD/locale) so I can
> store localization script message catalogs under the directory=20
> where
> I store the shell scripts. (This can be done using NLSPATH but it
> would be nice if it were on the default message catalog search=20
> path)
except for NLSPATH compatibility, almost all ast related file searches
key off the PATH environment variable
e.g., the ast file(1) magic file is found by searching for
../lib/file/magic
on $PATH
this simple mechanism makes it easy for any user (and ast itself)
to package, distribute and install file system position independent binaries
(1) install executables in $INSTALLROOT/bin
(2) install related files in $INSTALLROOT/<DIRECTORY>/<CATEGORY>/
the main property is that the absolute path of related files is never compiled
into any ast object/executable, which allows
(a) executables to be installed in any tree, and moved to other trees,
provided the related files are also placed in same tree
(b) users may populate selected related files earlier in PATH and override
installation defaults
for message catalog lookup this means that message catalogs could be placed in
the
following default directories searched for on PATH (using NLSPATH %X notation):
../share/lib/locale/%l/%C/%N
../share/locale/%l/%C/%N
../lib/locale/%l/%C/%N
so if the foo script were installed in
$ROOT/bin/foo
then the foo message catalogs could be installed in one of
$ROOT/share/lib/locale/*/LC_MESSAGES/foo
$ROOT/share/locale/*/LC_MESSAGES/foo
$ROOT/lib/locale/*/LC_MESSAGES/foo
and the catalog would be found by the default search
note that ast (and gnu gettext) require that the C locale message
must also be installed
> - Accurate and complete documentation. No use having a feature in=20
> the
> shell if it is not properly documented!
once these issues are resolved I'll do that
> I am sure others have different requirements. I suggest now is the time
> to put them on the table.
> - Finnbarr
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
