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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
