Re: beast module overview and i18n

[Christian Neumair <chris gnome-de org>]

Am Do, den 09.10.2003 schrieb Tim Janik um 00:40:
> so far, a plugin is a self-contained .so file, because even
> it's icon ("notch.png") is inlined in auto-generated code.
> i'd like to keep this property preserved if at all possible
> in the light of i18n. if translaters could tell us in
> what kind of format they would like sfidl to produce
> to-be-translated string lists and in what format the
> translations are best provided, we can hopefully work
> out a solution that allowes us to inline plugin
> translations as well.
Uhm I'm totally unaware of sfidl's way to output translatable strings.
Inlining plugin translations may become very hard since the .idl files
seem to be flat (no nodes). Usually inline translations are merged back
using convinience intltool macros only for XML-derived file formats.
Take a look at GConf schemas to see how this is implemented on a node
basis.
When it comes to runtime idl i18n, I propose the following:
- Add _() calls around the quoted UI strings inside the idl files so
that gettext recognizes them without much trouble. Else we'd have to
hack intltool (cvs module intltool) to accept your custom i18n notation.
- Add an sfidl i18n mechanism (specify gettext domain inside idl files,
actually add gettext calls at runtime, take care of N_(), too)

> in order to move on with 18n, i'd like in particular:
> - translators (i18n coders) tell me what they like don't
>   like about catalog-en.c
Please add N_() calls around the strings marked for translation. The
rest looks pretty good.

> - i18n coders to give me a clue about where i18n files
>   go (within the package and regarding installation dirs),
>   especially since the beast package consists of multiple
>   libraries that are possible candidates for future
>   seperation
They usually go into
$(prefix)/share/locale/$(LANG)/LC_MESSAGES/$(GETTEXT_PACKAGE).po when
they are installed.
We can have multiple packages, though - therefore separation is
possible.
Inside your package, they go into the po subdir. Just try to run
intltool-update -p inside po to generate a pot file (po template).
In addition, there could be added po-<subpackage> dirs. You should take
a look at the GIMP (po, po-libgimp, po-plug-ins, po-script-fu).

> - stefan, to give me an idea how reasonable and
>   on what time scale sfidl improvements and language
>   binding development are, to move BSE objects to idl
>   files so i18n string lists can be auto-generated
I18n strings shouldn't be generated but included as-is (in a way that is
accessible to gettext/intltool), since our translation status pages else
won't count these strings).

> - translators (i18n coders) tell me their thoughts on
>   translating plugins
In general a good idea.
Most packages (gedit-plugins etc.) do it the following way:
Basic plugin information (name, desc, etc.) is provided by XML files,
translations are merged back into them using intltool.
All core plugins use the same gettext package containing all plugin
translations.

regs,
 Chris