Re: Lampadas Bugzilla, status update, roadmap



mån 2002-08-12 klockan 10.49 skrev Andrew Sobala:
> > > I am not sure how you have implemented the translation infrastructure,
> > > but if you are in a position to be able to generate a lampadas.pot file
> > > and merge those results back in, then you can possibly take advantage
> > > of the gnome-i18n module. This is a collection of external programs
> > > which have their strings translated by the various GNOME teams and then
> > > the external maintainers merge in the translations from time to time.
> > > After creating the .pot file, pinging the gnome-i18n list would be a
> > > fruitful exercise (although I don't have to do any of the translations,
> > > so they may just want to kill me for suggesting more work gets pushed
> > > the way of the translators).
> > 
> > Our translation strings are all held in the back-end database after the 
> > initial install. They start out in XX.m4 files, where XX is the ISO code. 
> > We have scripts to walk these m4 files and generate SQL, which is used to 
> > insert data into the database. It would be unprofitable to convert to 
> > another architecture at this point, without a clear and strong benefit.
> 
> Correct me if I'm wrong, but I don't think it's necessary to keep
> translations in POT format.
> 
> >From what I understaqnd, if you can create a POT file either by using
> gettext itself or extracting strings in perl (this is what perl was
> originally designed for :) then you can take advantage of gnome-i18n and
> give the translators the POT files they're used to. More perl could
> merge the translations back into your m4 files.

This is basically what intltool does; maybe code could be stolen from
there, or lampadas adopted to use intltool. No need to reinvent the
wheel. ;-)
The point 1) below isn't trivial, so I think the most fruitful effort
would be to either use code from intltool, or use intltool for this.

As long as there is infrastructure for

1) generating a valid pot file (i.e. valid header, no msgid duplicates,
basically everything xgettext does)
2) correctly merging back the translations from the po files into
whatever format you prefer

then I think all requirements are met for smooth and efficient
translation by the GTP.


Christian





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]