See #9136.
(cherry picked from commit 0cd38a87e1)
Note: when cherry-picking, the tags were fixed as the main dev branch does not
need the underlined tags for localization anymore.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
appstreamcli on CI fails with error:
> E: org.gimp.GIMP:394: release-time-missing date
I didn't have such error on my local build, because it is a new check
only recently added. The CI appstreamcli errored-out this way.
It forces us to add a bogus release date since we don't know it yet. I
chose May 29, because we usually release on Sundays, and it might soon
be time to make a dev release (so who knows, we might get lucky and it
might happen this day), though it should not be taken as a promise or a
real plan just now. I just needed to fill something in, in order to fix
the CI.
I opened a report to ask that appstreamcli proposes a relaxed check mode
where we can test on the <release> tag before knowing the future date:
https://github.com/ximion/appstream/issues/398
appstreamcli returns an info message:
> I: org.gimp.GIMP:3: cid-missing-affiliation-gnome org.gimp.GIMP
Checking the message, it happens because the application ID does not
start with "org.gnome." (but "org.gimp.").
Double-checking AppStream docs, a note says:
> You should only identify with an umbrella project if you use all their
> infrastructure and policies, for instance string freezes dates,
> bugtracker and source control instance.
GNOME Foundation is indeed an umbrella for us for the infrastructure and
obviously part of its policies. But we are still independant and don't
depend on GNOME's freeze dates, or release dates, or design rules
(though we try to follow what makes sense), and so on. So I guess it
means we should not set this metadata tag? 🤷 Let's drop it.
See: https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group
Adding a TODO as date was passing through with appstream-util in relax
validation mode, but there is no such mode in appstreamcli.
Anyway since I have manual check steps for the AppStream files in
devel-docs/release-howto.txt, I never missed setting the date right (so
far! Knocks on wood…) in the AppStream metadata. Therefore let's drop
this trick for now and see how it goes.
It should fix the appstream unit check, but only when using appstreamcli
0.15.3 or over (this version is already on Debian testing).
See issue #8140.
It's better to start early as these need to be translated too and are
now even visible in GIMP itself.
Note that I wrote 2.99.11 in the version attribute, but only to be able
to test this easily during development. It will have to be edited to the
right version at release.
We want it to work whatever the level in the item tree. We only care
about whether the items are selected or not.
Also fixing the AppStream release tag for the description of this
feature.
Both files should always be synchronized (as development branch will one
day continue on the 2.10 series). Best practice would be that any change
to the AppData is first done on `master`, then cherry-picked to
`gimp-2-10` (even for stable release metadata).
It just says "The GIMP team" so it's kind of redundant/useless, but I
noticed that Flathub would just display an empty "Developer" section
because the tag is absent. Well at least it emphasizes the
community-developed side of GIMP.
Jehan