Selecting the needed po catalogs in the module dir

[Dag]

Luigi Toscano skrev den 2016-12-09 00:10:
> In data giovedì 8 dicembre 2016 20:44:34 CET, Friedrich W. H. Kossebau 
> ha
> scritto:
>> Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb Dag:
>> > Boudewijn Rempt skrev den 2016-12-08 11:53:
>> > > 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?
> 
> Parsing the Messages.sh file. See the attached functions which comes 
> from the
> work in progress (you can use it in the scripts which a license which 
> matches
> the KDE Policy license), the extraction works well in my testing.

Where in the infrastructure would this go?

Just for the record, the script will not work out of the box for 
calligra because we have construct like:
calligra_xgettext calligra.pot $LIST
but we could of course change all Message.sh to conform to requirements.

> 
> 
> My long term idea is to get rid of Messages.sh and use a declarative 
> format
> (which can be a simple INI file) to define which translation files 
> exists and
> which files are associated to them, with a separate engine with 
> pluggable
> support for different translatable artifacts (regular gettext, json, 
> etc).