> [ ... many thought about localerc deleted ... ]
> Well, you are right in all your points. I just decided
> to use a new file because I don't need much functionality
> and therefore could keep it simple as well as the functions
> in GIMP and libgimp to deal with it.
IMHO adding lines into the pluginrc is much easier than to add
code to parse another file.
> > So why, I ask you, don't we just put the locale information
> > into the pluginrc. It should be trivial to extend the parser
> > to optionally read two additional lines after the proc-args
> > in the form of:
> > (locale-domain "funky_plugin")
> > (locale-path "~/.gimp-1.1/po")
> Yes, this was an idea, too. But like you said:
> - need to expand the parser.
Which just means adding another token to the parser code. You can't do
much wrong here.
> - need to check the domainlist for duplicated entries on
> every addition of a new domain otherwise we'd have possibly
> hundreds of gettext calls for a translation lookup.
Which you will have to do in any case. Actually I don't see hundreds
of internationalized plugins in addition to the ones that come with
gimp and even if there were hundreds, iterating through a list of
strings and comparing them is pretty fast. If that's not enough, we
could always a hash...
> - need to add parsing functionality to libgimp to write the entries
> to pluginrc.
Eeek, no! Libgimp doesn't have to know much about this at all. The
plugin would just call a second special gimp_install_domain()
procedure if it needs to register a domain. Of course this means
adding a new type to the gimpprotocol, but I see no substantial problem
in doing so.
> or instead of the last point we'd need to change the wire protocol
> and add additional fields to the plugin structures and thus introduce
> an imcompatibility.
Your additional libgimp function introduces the same incompatibility.
There's no way to avoid this. To make it clear, I don't speak about
changing the gimp_install_procedure(). I totally agree with you that
adding a function like gimp_set_domain() to the query() part of the
plug-ins is the way to go.
I just do not see your point in keeping this very plug-in-specific
info out of pluginrc where it belongs. app/plug_in.c contains all
the code you need to parse and write the pluginrc. Additionally
there's code to keep the plugin info in sync with the actually
installed binaries. Your solution is very weak when it comes to
that point and I see some substantial problems in that weakness.