RE: new release of the gnome-system-tools
- From: "Carlos Garnacho" <garnacho www tuxerver net>
- To: Christian Rose <menthos gnome org>,Carlos Garnacho <garnacho tuxerver net>
- Cc: "Francisco J. F. " Serrador <franciscojavier fernandez serrador hispalinux es>,GNOME I18N List <gnome-i18n gnome org>
- Subject: RE: new release of the gnome-system-tools
- Date: Tue, 30 Dec 2003 14:03:45 +0100
On 30 Dec 2003 01:16:10 +0100, Christian Rose wrote
> mån 2003-12-29 klockan 20.52 skrev Carlos Garnacho:
> > > > I think those strings should be merged with the other. Carlos do you
> > > > plan to do it in the future?
> > >
> > > I agree, but I don't think Carlos Garnacho is subscribed to this list.
> > > I'm CC:ing him.
> > sorry, this thing isn't likely to happen :/, one of the objectives that
> > the GST had was to make the frontends independent of the backends, for
> > example, the backends now can be installed in a computer and use the
> > frontends from other computer to access them, or other projects (such as
> > knetworkconf) may use it. I think that proper i18n in the backends is
> > essential for this objective
> Then I suggest you put the backends in a seperate module.
> Having multidomain modules with several po directories has always shown
> to be a recipe for translator confusion, configure.in breakage, and
> general problems with the config toolchain in the past.
> Also, from your description, it sounds like you aim to seperate the
> backends anyway. Then you might aswell do it in a seperate module
> that easily can be independantly maintained and released IMHO.
As Danilo said, the backends are already in another module, and it's very
likely that in the next release the link to the backends is deleted, so the
frontends module will simply depend on the backends module through pkgconfig,
yesterday night I tasted the configure.in ingredient of your recipe and
didn't like it very much :)
Carlos Garnacho <firstname.lastname@example.org>
] [Thread Prev