beast module overview and i18n

[Tim Janik <timj gtk org>]

hi all.

since christian started out with introductionary i18n changes to the
code base, here's a rough overview of the current module structure,
possible approaches to i18n and remaining problems:

- beast (beast/beast-gtk/) - main GUI app;
  uses GXK, BSW, BSE, SFI
  needs i18n as it contains GUI visible strings
- GXK (beast/beast-gtk/gxk/) - static wrapper and add-on library around Gtk+
  uses Gtk+, GLib, glib-extra.h (from sfi/glib-extra.h)
  needs i18n as it contains GUI visible strings
- bsesh (beast/shell/) - Scheme Shell
  uses BSE, SFI, libguile
  can probably go without i18n. is the guile executable i18n-ed?
- BSW (beast/bsw/) - very slim autogenerated C language wrapper around BSE
  uses BSE
  no need for i18n as it doesn't contain user-visible strings
  * scheduled for removal at a future development stage
- Plugins (beast/plugins/) - mostly synthesis modules. could possibly live
  outside the beast package
  use BSE, SFI
  need a proper i18n solution that also works for third-party plugins
- BSE (beast/bse/) - sound synthesis library, plugin framework etc...
  uses SFI, sfidl
  needs i18n as it contains GUI visible strings
  * could become its own package at a future development stage
- SFI (beast/sfi/) - fundamental type/communication layer. wraps parts of GLib
  and GObject. probably doesn't even need to be i18n-ed.
  * scheduled to become its own package in the not too distant future
- sfidl (beast/sfi/sfidl) - idl compiler
  no direct need for i18n, but needs to generate a list of strings
  from idl files that need i18n

for beast, i18n is supposed to happen by translating
beast/beast-gtk/catalog-en.c. GUI parts that aren't covered by that
catalog yet need to be changed to use it, rather than be i18n-ed in place.

for BSE, most of what needs i18n are object property names. these
are not currently marked up in the code with _(), because objects
are supposed to be defined in idl files at some point, and from idl
files, we can auto-generate the list of property names and descriptions
that need i18n.

crucial to i18n here is getting sfidl improved to have most
BSE object definitions moved to it.

finally there're plugins for beast. with the upcoming 0.5.5 release,
plugin development has been significantly simplified, since we moved
to an sfidl based solution with lots of the necessary code being
auto-generated. the usual plugin now consists of:
- a moderately small C++ object which implements the synthesis
  process() method
- an idl file which contains definitions of the object API, i.e.
  properties, using names and descriptions in the canonical plugin
  implementation language
- an icon for the GUI which is part of the idl file definition and
  is inlined into the auto-generated code for the plugin

from the idl file, a header file is being generated, so the
average plugin build process involves no more than (simplified):
%.h: %.idl
	sfidl $<  > $@
%.so: %.cc %.h
	gcc -O2 -Wall $< -o $@

and a sample plugin idl file might look like:

#include <bse/bse.idl>
namespace Example {
class NotchFilter : Bse::Effect {
  Info    icon      = "notch.png";
  Info    category  = "/Modules/Examples/Notch Filter";
  Info    blurb     = "Example::NotchFilter is a sample implementation of a notch filter in C++.";
  IStream audio_in  = ("Audio In", "Audio input to be filtered");
  OStream audio_out = ("Audio Out", "Filtered audio output");
  group "Notch Settings" {
    Real    freq    = Freq ("Frequency", "Frequency around which the notch to center", BSE_KAMMER_FREQUENCY_f, SFI_PARAM_HINT_DIAL SFI_PARAM_DEFAULT);
    Real    gain    = Gain ("Gain [dB]", "Specify the notch level in decibell", -3, -48, 0, 3, SFI_PARAM_DEFAULT SFI_PARAM_HINT_DIAL);
  };
  group "Filter Settings" {
    Real    quality = ("Quality", ("The quality adjust how much neighbouring frequencies are affected "
                                   "by altering the notch frequency"),
                       1, 0.01, 10.0, 1, SFI_PARAM_DEFAULT);
  };
};
};

here, subject to i18n are:
- the category ("/Modules/Examples/Notch Filter")
- the blurb ("Example::NotchFilter is a sample"...)
- the IStream/OStream nick and description ("Audio Out", "Filtered audio output")
- the property nicks and descriptions ("Gain [dB]", "Specify the notch level in decibell")

the idl compiler can easily be extended to generate a list
of exactly and only the strings listed above, so i18n
contributors can translate the correct set of strings
in one go.

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.


so much for the rough overview.

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
- 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
- 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
- translators (i18n coders) tell me their thoughts on
  translating plugins

other comments are of course also apprechiated ;)

---
ciaoTJ