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

Friedrich W. H. Kossebau kossebau at kde.org
Thu Dec 8 19:44:34 GMT 2016


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.

@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