Re: beast module overview and i18n

[Tim Janik <timj gtk org>]

On Thu, 9 Oct 2003, Christian Neumair wrote:

> 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)

we'll probably go for something different, where the idl compiler
produces a message file that contains all strings to be translated.
that way we can spare mark up of strings in idl files.

> > 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.

ok, the file got renamed to bstmessages.c and has its strings
marked up now. so there's lots to translate in de.po now ;)

> > - 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).

i did. we now use versioned beast and bse message catalogs.

> > - 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).

you basically want all strings that need translation to sit readily
available in CVS. that's fine, we can have the idl compiler generate
the required strings file and keep the generated version up-to-date
in CVS.

> > - 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.

yes, i'll probably set up a po-plugins/ dir at some point, and just
translate packaged plugins. there're a bunch of sfidl TODOs that have
to be taken care off before that though.

in any case, thank you very much for your work
and patch on getting i18n started.

>
> regs,
>  Chris
>

---
ciaoTJ