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).