Re: gettext and bugzilla for beast

[Tim Janik <timj gtk org>]

On 5 Oct 2003, Christian Rose wrote:

> sön 2003-10-05 klockan 01.50 skrev Tim Janik:
> > > Are there any plans for enabling gettext/intltool support in beast?
> >
> > hm, in principle yes. we're not actively developing on gettext
> > integration currently, because the TODO is full of other stuff,
> > and because no one attempted to translate beast yet.
>
> I see a catch-22 here :-)
> Most likely noone has been interested because the effort of
> gettextifying beast now, when it has grown into a very large codebase,
> is a substantial entry barrier. And the vast majority of translators
> interested in translating are very likely to not know how to gettextify
> an application to begin with.
> So I'm a strong believer in enabling gettext support early on in the
> development process when a small codebase should make it much simpler.

right, though i've always had gettextization in mind, so there's
not all hope lost with the current code base ;)
for instance: while not every string that needs it has _() around it,
we are migrating most of the BSE objects to an idl based solution, and
the idl generator can easily surround the correct set of strings
with _(). so gettextization here is "merely" a matter of porting the
rest of our objects ;)
and for the GUI objects (widgets), i've recently started out to
move all tooltips/labels etc. into a central message catalog,
partly to make i18n easier and partly to make GUI improvements
easier. so here, it's a matter of internationalizing one source
file, and moving the rest of the GUI labels to the new mechanism.

> That being said, Christian Neumair (Manny) expressed some interest in
> gettextifying beast. Manny?

that'd be good. as i said, it requires someone to put energy
into i18n, and i'm kinda busy with other things in beast,
though i'm willing to provide help and already set the necessary
fundamentals to get i18n going at some point.

there's one remaining issue though, that's i18n for plugins (dynamically
loadable .so's, not programs) and how the core gets its hands at the
message catalogs of plugins. but we'll hopefully able to solve that
after the core got proper internationalization and i got some more
experience with gettext ;)

> > so basically, it takes someone willing to put some time and
> > energy into a translation for gettextization to really emerge.
>
> Well, the translations can't come until the application supports
> gettext. Translators aren't likely to copy/paste each of the hundreds of
> messages out of the source by hand and create their own pot and po files
> manually that way. ;-)
>
>
> > > Are there any plans for having a beast bugzilla product in
> > > bugzilla.gnome.org, for that matter?
> >
> > well, beast is supposed to use a bugtracker at least theoretically.
> >
> > i personally don't like bugzilla.gnome.org very much, because
> > it doesn't have a usable email interface (and i'm not
> > fond of using webinterfaces for bug trackers).
> > due to that, i'm notoriously bad at handling glib/gtk+ bugs in the
> > bugtracker, and i don't want things to become as bad for beast
> > as well.
> > so basically, i've been looking for a bug tracker like debian's
> > where beast's bugs could be administrated, and been talking to
> > bugzilla.gnome.org admins to get it working with a decent email
> > interface, none of which was very fruitfull yet though.
>
> Fair enough. I was just wondering where I should send beast bug reports
> knowing they wouldn't get lost or forgotten.

currently, the canonical place if there's any, is this list ;)

>
> Christian
>

---
ciaoTJ