Subject: gettext support

From: Olivier Chapuis <[email-masked]>
Date: Mon, 25 Nov 2002 20:31:51 +0100

Hello,

I would like to add Native Language Support to fvwm by using gnu
gettext.

This should go as follow:

1 - Add checking for gnu gettext (in the libc or in an external
lib libintl). This concerns configure.in & acinclude.m4 and some
Makefile.am. These leads to some usual changes plus some strange
gettext hack.

2 - Adding a new directory po/ which comes from the gettext package and
modifying it for our use. Developer will be able to add catalogs (fr,
de, ...etc) set the C files where some string needs translation and
generate "po" files for translation. After translation, developers
generate the ".(g)mo" binary files from the .mo one's. So all these
po/(g)mo files will be on cvs and in the dist (no autogeneration).
make will do "nothing" and make install will just install the
(g)mo files. So users do not need the gettext package (only a recent
glibc or the good intl lib). Developers (which want to manage the
po/ directory) should use the same version of gettext
(last stable 0.11.5).

The good news is that it will be possible to --disable-nls and to
restrict the "catalogs" to install (using the LINGUAS env
variable). The bad news is that there is a few autoconf non standard
things to do. For example, the po/ directory do not has a Makefile.am
but a Makefile.in.in :o/ and the autogeneration of the Makefile is
strange. The gettext authors also suggest to add the intl lib in the
source to provide NLS support for those which does not have a recent
glibc or libintl. I do not think this is a good idea. For more info:
info gettext. 

3 - add the usual library warping stuff (FGettext.h and FGettext.c)

4 - replace the string (in the C code) of the form 

	"to_be_translated"

that we want to translate by:

       _("to_be_translated")

(needs some small workaround).

At this point we should decide which strings we want to translate.
Do we want to translate fvwm_msg (I do not think so, at least now)?
Do we want to translate fvwm options related msg (I think yes)?
Do we want to translate the "screen msg" (yes)?

5. Add a new "extended variable":
 
    $[gt.String]

where String is an arbitrary (ASCII) string. If the string "String"
can be found in the fvwm catalog replace $[gt.String] by its
translation. If not replace $[gt.String] by "String".

6. At this point we can use 5 for some of our samples (rc and Form).
This will gives translation for some words which are used in
a wm config and 5. will be more useful.
A problem is that it seems that xgettext is no able to properly
extract the strings to translate from a fvwm config file. We should
write a tool (in perl) that can build a "pot" file from a set of fvwm
config file.

7. A new fvwm command 

    LocalCatalogs dir [domain]

(better name welcome) which will look for translation into
an aditionnal set of "user" catalogs:

    dir/LL/LC_MESSAGES/domain.mo

with domain=fvwm by default. This maybe useful for project
as fvwm-themes or for administrator.

8. Do somthing special for FvwmScript

Objection? Comments?
I've already done 1 to 5 (at the experimentation level).

Olivier
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 26 Nov 2002 02:48:33 +0000

>From your description it seems like gettext is pretty problematic.
My first reaction for including this was negative. But when I think more
about it, users in euro-asian (and other) countries should like this.
I predict a lack of translation maintainers, but this should not be a
reason not to have it. I may maintain 2 languages, but I prefer someone
else to do this if possible. :)

> Makefile.am. These leads to some usual changes plus some strange

I will add fvwm-config --fvwm-localedir or similar.

[snip]

> Do we want to translate fvwm_msg (I do not think so, at least now)?

Is it possible to have something like  msg = _(msg);  in fvwm_msg
itself? If yes, it may be done. We don't need to actually translate
every string (or any string) if I understand it correctly.

> Do we want to translate the "screen msg" (yes)?

Ok.

> translation. If not replace $[gt.String] by "String".

Seems very useful, without this I would be less enthusiastic.
Just a note, String should be able to contain '\n' and '\]'...

> write a tool (in perl) that can build a "pot" file from a set of fvwm

I don't think we need to translate our samples. And if we translate them
I can't see how it is possible to create a list of messages automatically.
It is an AI job to decide whether "red" should be translated or not.
This is not needed, IMHO. Also try this:

  perl -ne 'print "$1\n" if /"([^"]+)"/' file1 file2

> as fvwm-themes or for administrator.

LocalePath? Similar to our other *Path commands.

  LocalePath /usr/share/locale;fvwm:+:/opt/fvwm/locale

Both dir and domain may be optional if there is ";".
Dir defaults to $datadir/fvwm/locale.

> 8. Do somthing special for FvwmScript

Hmm, I see what you mean. :)

I just thought about how it is possible to add the gettext support to
perllib and I see a pretty good solution.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 26 Nov 2002 12:58:44 +0100

> else to do this if possible. :)

Yes, if we do not setup a gettext infrastructure we will be sure to
do not have translator maintainers. I am ready to maintain French
translation.

> I will add fvwm-config --fvwm-localedir or similar.

Yep.
 
> Just a note, String should be able to contain '\n' and '\]'...

Yes.

>   perl -ne 'print "$1\n" if /"([^"]+)"/' file1 file2

When I say "translate our sample" it just means to replace certain
strings as
 
	+ I "Programs" Popup MenuProgram

by

	+ I "$[gt.Programs]"  Popup MenuProgram

then we should be able to extract only the String which appear
as $[gt.String] from our rc sample:

	perl -ne 'print "$1\n" if /\[gt\.(.*)\]/' file1 file2

(is this ok in all situation?).

> Hmm, I see what you mean. :)

The special thing is to just add gettext support to FvwmScript.
As fvwm read the config for the modules, modules will do
not need gettext support. Only FvwmScript and FvwmTaskBar need
it (I think).

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 26 Nov 2002 13:29:06 +0000

> (is this ok in all situation?).

The following is ok in all reasonable situations:

	perl -ne 's/\[gt\.((\\.|.)+?)\]/print "$1\n"/ge' file1 file2

i.e. with something like:

	+ I $[gt.Programs] Exec xmessage $[gt.\[Error\] Can't read file]

$[gt.Programs] properly adds quotes, so should not be placed in quotes.

Regards,
Mikhael.