Function fmtfmt(), translate(), and localized messages

[krader1961]

This project does not contain any localized message files. That is, translations of English messages embedded in the code. This came to my attention because function fmtfmt() (which has a modest amount of lint warnings) is only called by translate(). Yet the project contains no localized versions of the various messages it emits. Thus none of the unit tests exercise the code to translate messages, error or otherwise, emitted by ksh.

Googling various phrases such as "ksh message localization" did not return any results that would imply anyone has actually created a localized version of the English messages embedded in the code. Other projects I've worked on (e.g., the fish shell) contain localized message sets. Which makes it relatively easy to know when changing an existing message, or adding a new, requires localization updates. Am I missing something patently obvious with respect to how localization of ksh messages is handled?

The most relevant document I could find was from @fpmurphy in 2009: https://blog.fpmurphy.com/2009/05/ksh93-message-localization.html. That it makes it pretty clear that the current code does not support localization of messages in scripts and the existing code makes adding such support difficult. Note that fish uses the GNU gettext internally. In scripts it uses the command of the same name if possible else it just echos the untranslated message. Is there some reason this project shouldn't take the same approach to the problem?

[dannyweldon]

I have done some experimentation with localisation based on another one of Finbarr's examples from 2010 and found it fairly easy to do.

https://blog.fpmurphy.com/2010/07/localizing-korn-shell-scripts.html

Looking in the ast source code, and as Finbarr points out, I found that it supports loading a message catalog via a path relative to the ksh script, which makes it very handy for creating location-independent ksh packages. I'm not sure if gettext supports this. (See mcfind() in mc.c)

For example, say I have a ksh package called hello with a directory structure with message catalogs like this:

bin/hello
lib/locale/<LANG>/LC_MESSAGES/hello

and with specific catalogs:

lib/locale/C/LC_MESSAGES/hello
lib/locale/fr/LC_MESSAGES/hello

All I have to do is add the full path of that bin directory to my PATH and set

LANG=fr

then my script gets automatically translated and I don't have to mess with NLSPATH, although the message catalogs must have no extension. It would be nice if it checked for files with a .cat extension as well without having to set NLSPATH to explicitly specify it.

I also needed the msggen command to compile the catalog.

[krader1961]

@dannyweldon, Yes, I agree that shells should make it easy to localize the messages in the programs (i.e., scripts) they run. Kudos to the ksh team for making it somewhat easier than doing so in other shells. For comparison: bash. But the fact remains that the core messages are not localized. A fact that is rather surprising even in the year 2012 when ksh93u+ was released; let alone today. If the current message translation mechanism is to be retained we really need to add some tests of that functionality. As well as some alternative language catalogs for the core messages.