Re: Specifying catalog path in gettext

[Bruno Haible]

Hello,

[CCed to address@hidden because it's a question of general interest.]

Ricardo García wrote:
> Hello,
> 
> I'm writing you regarding the current mechanism applications have to use to 
> install and specify the catalog path when using gettext. Full story follows.
> 
> Some months ago I started writing a program in Python. I wanted its output to 
> be translated into the user language, so I used Python's gettext facilities. 
> My problem came when packaging the program. I realized I should install the 
> translation messages to /usr/local/share/locale when I was using 
> the /usr/local prefix and /usr/share/locale when I was using the /usr prefix. 
> Being a script, the only proper approach to this was to do an in-place 
> substitution in the script body, what I considered a dirty hack (sort of).
> 
> I started to think about the problems of the current way of specifying the 
> "dirname" part of the catalog. If you specify your own, that one is used. If 
> you don't specify one, it uses a system-dependent one which is not fixed and 
> has to be obtained by parsing the output of "gettext -h" (is there a more 
> convenient way of getting this information?) and cutting the line and such...
> 
> When I think about it, I realize that the problem gettext has to resolve is 
> to 
> find a file in the system, according to a keyword (catalog name). Many other 
> programs in the system solve this problem too and provide a more convenient 
> approach. It happens, for example, when you type "man <program name>" or 
> simply a program name the shell has to run. In those two cases, environment 
> variables are used to provide search directories in runtime instead of 
> compile time. By changing PATH or MANPATH, you can alter the behavior, 
> change the results, without doing hacks. I'm sure I'm not the first one to 
> come up with this idea. What do you think about it?
> ...
> The current execution flow inside the library doesn't ease implementing some 
> sort of GETTEXTPATH environment variable usage ...

Two answers are possible.

1) MANPATH is a good example, because it illustrates the main flaws of this
   approach:
     - The lookup is slow. "man printf" takes two of three seconds before
       it even starts to format the appropriate manual page.
     - The results are often not correct, because a user normally doesn't
       think about keeping MANPATH in sync with PATH - so he gets into the
       problem that, say, "which foo" would execute /opt/bin/foo but
       "man foo" reports the manual page of /usr/local/bin/foo.

   Nowadays, a program comes packaged with its manual page and its message
   catalogs - it doesn't matter whether the user installs a .rpm file,
   a tar.gz file with relocatable files, or does the "make; make install"
   from source. So there is usually one location to look for the man page
   (or at most two, when you consider the confusion between $prefix/man and
   $prefix/share/man). MANPATH predates this package installation convention.

2) From the point of view of a user of internationalized programs (KDE,
   GNOME, command-line programs) you did not notice a problem that would
   demand the introduction of a GETTEXTPATH environment variable. So
   apparently as a user you are happy with the status quo. But as a developer
   you have a problem... and what you propose would make the gettext()
   results slower and less reliable for the users. So you are pushing a
   problem away from the developer to the user... There are many more users
   than developers. Therefore it's preferable to push problems from the
   users to the developers.

> Do you think using some sort of GETTEXTPATH is more convenient?
> Do you think it can be implemented easily?
> If so, could you write that code?
> If not, would you help me or give me advice about how to write that code?

Good questions, but the answer to the first question is already "no".

> Do you think a simpler approach like specifying only one directory through 
> some sort of GETTEXTDIR environment variable is more feasible?

You are aware that programs can invoke other programs, and that environment
variables are inherited across invocations? When for example a program
installed in /opt/kde3 invokes a program installed in /usr/local, what
should the value of GETTEXTDIR be at the various points? You imagine the
hassles that this would introduce?

> So I downloaded the source code for gettext 0.14.5 ...

Incidentally it already contains a possible solution for your problem.
Take a look at gettext-tools/examples/hello-python/:

  gettext.textdomain('hello-python')
  gettext.bindtextdomain('hello-python', '@localedir@')

"configure" substitutes the right pathname in the script. You don't consider
that a "dirty hack", I hope?

> Thanks for your time and sorry for the long mail. Kind regards,
> 
> -Ricardo García

Best regards as well,

                       Bruno