Re: [nls 00252] Re: gencat

[Ulrich Drepper <drepper at redhat dot com>]

"Yoshito Kawada" <KAWADA@jp.ibm.com> writes:

> ( I am not sure if I understood this portion correctly. "package" means run
> time application ? )

Package means the sources or binaries (.tar.gz, rpm, ...) which are
installed.  The message catalogs come in source form and are compiled
for the appropriate target at installation time.  This will not be
possible for those catalogs which require special locales or
conversions since they cannot be assumed to be available.

> Of course, on the environment on which gencat runs, the
> corresponding locale and iconv modules must be installed, but glibc
> has all of them by default, doesn't it?...

First, packages are targetting more than Linux.  Second, not
everything must be available.  People are free to remove conversion
modules, for instance, they don't need.

> No argument is required to this option.  Instead, gencat users have to set
> LANG environment variable that corresponds to the charset of the message
> catalog. In other words, this option allows gencat to switch between the
> original gencat logic and Mr. Hanataka's logic which depends on
> multibyte-wide character conversion, which in turn requires LANG
> environment variable appropriately set.

Well, this is a blow against every package maintainers efforts to make
her package usable by many.  It would require individual rules for the
installation of every single catalog.  You have to select the
appropriate locale.  Currently the installation happens most probably
in a loop like

   CATALOGS = ja de
   for f in $CATALOGS; do
     gencat $f.cat $f.msg
     cp $f.cat /usr/lib/locale/$f/LC_MESSAGES
   done

Support for a new language means adding to the CATALOGS variable.  If
you force people to write special rules for each catalogs all you'll
achieve is that languages which require this special behavior are not
supported.

> As far as our gencat is concerned, they rely on LANG environment value just
> the same way I said above. Therefore, makefiles of the applications have to
> include the statement to set the LANG prior to gencat.

Well, look around at the packages which use catgets.

> Yes, that's right.  The person who creates makefile must know the encodings
> of each message catalog, which could be error-prone.

You also must not make the mistake of believing that the package
maintainers know anything about these issues.  These are the same
questions we took into account when creating the gettext framework.
Maintainers most of the time have no clue about internationalization
and if you want them to at least distribute the work contributors
provide you have to make the maintainer's job easy.  Very easy, like
adding an entry to a variable.

> All in all, I completely agree that your method is smarter.  However, my
> only concern is that there exists tons of message catalogs created in the
> past without "$ charset= ..." naturally, and it takes tremendous effort to
> insert "$ charset= " to each one of these.

No, it doesn't take much of an effort.  Simply run

sed '1 {i\               
$ charset=sjis
}'

over all the catalogs you want to mark with SJIS.  If the name of the
charset is encoded in the catalog file or path name it is even possible
to automate the whole process for all charsets.

> Compared with that effort, editing makefile would be smaller in
> workload.

This is where you are wrong.  You are thinking with the mindset of a
corporation programmer where there are people who's job it is to do
this and who know what to do.  This won't work for free software
packages where you sometimes have to beg maintainers to care about
internationalization enough to distribute message catalogs.  If they
are required to do more than keeping track of the files they won't do
it (correctly).  We've done extensive studies when designing the
gettext model to reach this conclusion.


I'm more than ever convinced it should be up to the translator to
provide the information since s/he is the only one who knows the
issues involved for sure.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------