[EMAIL PROTECTED] wrote:
> Hi developers,
>
> as you might know that gettext solution works quite nice for
> GIMP itself but may cause trouble with plugins. To circumvent
> the problem that every plugin must have it's domain registered
> within the GIMP source, I'll offer you a new idea here:
>
> 0. Foreword
> Basically we can't get away from gettext and switch to a better
> system (which would have to be written first, too) that short before a
> release like at the moment. Thus my goal was to change as little as
> possible. Like you'll see, we'll just have to add a line to every
> plugin outside the GIMP distribution to make this work; everything
> else stays the same like it is now, even the catalogs remain untouched.
>
> 1. Ideas
>
> 1.1 The config file
> The current system is a very static one i.e. nothing can be changed
> neither without the sourcecode nor after compilation. What we need
> is a dynamic system to remove that deficiencies. A good way to bring
> some dynamic into a system is to make it configurable for example by
> having a config file.
> This configfile of course shouldn't have to be modified by an editor
> but automatically by the GIMP resp. libgimp.
>
> 1.2 Plugins with libgimp
> To get this information in there we'll provide a funtion call in
> libgimp which registers the domain from the name and path the plugin
> CAN provide. If the domain hasn't been registered yet it'll its way
> into the configfile
>
> 1.3 The GIMP core
> The GIMP uses the information from this file to bind the necessary
> catalogs to itself. To actually use this bound domains we'll have to
> provide a function which won't look up a message in one catalog but
> recurse through all of them. This function will replace the gettext
> call just in places where the GIMP would lookup a menuentry which
> is sometimes not in its own catalog.
>
> 2. Implementation
>
> 2.1 The configfile
> Like all other configfiles this one will stay in ~/.gimp-<Version>.
> The first line contains ":gimp" to ensure that no one messed up this file.
> The next lines contain the name of the domain, a withespace and the
> location of the catalog. One catalog per line.
>
> 2.2 Plugins with libgimp
> For the plugins we'll have two new functions in libgimp/gimpdomain.c
> which have the selfexplaining prototypes.
>
> gimp_domain_add (gchar *)
> and
> gimp_domain_add_with_path (gchar *, gchar *)
>
> Every plugin may register a domain but don't has to necessarily.
> The functions call another static one which checks whether the files
> already exists and whether the domain is already registerd. If so it
> won't be registered again else it will.
>
> 2.3 The GIMP core
> GIMP will call initgettext() at startup which will initialise i18n
> if compiled with it and setup a default (and fallback) domain "gimp"
> and every domain that it'll read from localerc.
> Every occurence of gettext which had been used to translate menunames
> will be changed to gimpgettext which consists of a loop which checks
> for a possible translation in all domains which were read from
> localerc.
> At the end GIMP'll call freegettext() to clean up everything.
>
> 3. Conclusion
> This idea will cirumvent most of the problems which gettext alone
> just can't deal with. It's little and as such not very likely to
> introduce many new bugs. It would allow us to ship GIMP 1.2 with
> the possibility to add plugins which will also benefit from
> localisation without any hassle.
>
> Patch against current CVS is appended. Please feel free to contribute
> further ideas and to comment this stuff.
Well, for quite a while I haven't liked gettext, and consider it very outdated.
Problem is, a good replacement with a good license would need to be out there to
switch to.
This is sounding better, but maybe you should take a look at the work Taligent did
on this front. Their work went into Java 1.1 for it's internationalization
support. What you're proposing sounds very similar to Java's
PropertyResourceBundles. You should review this lesson in The Java Tutorial to get
an overview:
http://java.sun.com/docs/books/tutorial/i18n/resbundle/index.html
One of it's features that is very useful is it's hierarchical lookup and fallback.
So it first looks for/in the most specific file (e.g. resources_fr_CA_UNIX) then
starts trimming the extensions until it finds the resource.
IBM also has the same functionality released as the IBM Components for Unicode
(ICU). Unfortunately it was initially under a license that was not friendly to
GNU.
http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html
Hmmm. It's now under a license that has been approved by OSI. Maybe it's a good
candidate for Gimp use now?
http://www10.software.ibm.com/developer/opensource/license10.html
Even if it's not directly useable, the manner in which they do certain things
might be good to think about.
