On Tue, Nov 26, 2002 at 02:48:33AM +0000, Mikhael Goikhman wrote:
> On 25 Nov 2002 20:31:51 +0100, Olivier Chapuis wrote:
> >
> > I would like to add Native Language Support to fvwm by using gnu
> > gettext.
>
> >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. :)
>
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.
> > 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.
>
> I will add fvwm-config --fvwm-localedir or similar.
>
Yep.
> [snip]
>
> > 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)?
>
> 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 fvwm options related msg (I think yes)?
> > Do we want to translate the "screen msg" (yes)?
>
> Ok.
>
> > 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".
>
> Seems very useful, without this I would be less enthusiastic.
> Just a note, String should be able to contain '\n' and '\]'...
>
Yes.
> > 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.
>
> 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
>
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?).
> > 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.
>
> 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. :)
>
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
--
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]
