Selecting the needed po catalogs in the module dir (was: Re: calligra 3.0.0 tarball)

Albert Astals Cid aacid at kde.org
Thu Dec 8 20:55:16 GMT 2016


El dijous, 8 de desembre de 2016, a les 20:44:34 CET, Friedrich W. H. Kossebau 
va escriure:
> Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb Dag:
> > Boudewijn Rempt skrev den 2016-12-08 11:53:
> > > On Thu, 8 Dec 2016, Dag wrote:
> > >> Boudewijn Rempt skrev den 2016-12-08 11:13:
> > >> > On Thu, 8 Dec 2016, Dag wrote:
> > >> > > Hmmm, well does this mean krita translations will be
> > >> > > released/packaged
> > >> > > with
> > >> > > calligra release? If so, there is bound to be problems sooner or
> > >> > > later. Or
> > >> > > is/can this be taken care of in some way?
> > >> > 
> > >> > I guess I can add some code, if I remember a bit of ruby (it's years
> > >> > since
> > >> > I last used it) to skip everything that sounds like krita or kexi.
> > >> 
> > >> Yes well, when calligra is released, when krita is released skip
> > >> calligra/kexi, and when kexi is released...
> > >> Maybe the best solution, but doesn't sound great.
> > > 
> > > Well, for Krita, we only have krita.po with everything in it -- so that
> > > works
> > > out automatically. I'm not sure about kexi, though.
> > 
> > Ehhh, no not quite, there is also desktop_calligra_krita.po and
> > org.kde.krita.appdata.po, but still...
> 
> Po catalogs like *appdata.po, desktop_*.po, json_*.po are not to be included
> in the release tarballs, those are just some translation process artifacts.
> Their content is merged into the sources already every time scripty runs,
> have a look e.g. into the appdata or desktop files. Thus no need for having
> another copy by the separate catalogs, nothing will use them at runtime.
> (IMHO they would be in a separate namespace on the server to not confuse
> release managers, but such a change did not have enough supporters:
> https://marc.info/?l=kde-i18n-doc&m=146615836224833&w=1)
> 
> So Krita just packaging krita.po files is correct, as they only have that
> one single runtime catalog file for all of the Krita source code.
> 
> > My concern is the future when something is added/changed.
> > 
> > I can't see more than two possible sustainable solutions:
> > Best: split calligra, kexi and krita properly both in git and svn.
> > 
> > Not so good: Make some cmake magic to install only the po files we can
> > generate pot files for. This will work for all of us, except that there
> > will be another special solution to maintain. But it will not solve the
> > "problem" that it is less straight forward for the translators as always
> > only parts of "calligra" (as they see it) is released.
> 
> Another hack might be to have some script to find all Messages.sh in the
> source code and extract the catalog name from them.
> Either by crude parsing the existing ones and grep for the <name>.pot
> content, or a more engineered approach by adding code to all Messages.sh
> files to output the name of the catalog file(s) created when called with
> some argument like --just-dump-the-catalog-base-name-please.

yes, this, i asked for people volunteering to make a proposal for this a while 
ago, noone raised their hand though.

Cheers,
  Albert

> 
> @Luigi, IIRC you are working on a similar challenge when it comes to KDE
> Application tarballs, where in the future the po files should be inside the
> respective source code tarballs, no longer in a separate one.
> What approach are you taking there?
> 
> Cheers
> Friedrich





More information about the calligra-devel mailing list