openSUSE Release Process

Some more hints:

$ osc getbinaries openSUSE:Leap:42.2 vym standard x86_64
$ cat binaries/vym.desktopfiles

to reproduce locally brp-trim-desktopfiles must be in the build root (osc build -x brp-trim-desktopfiles). Or put it as Supports: in prjconf (see osc meta prjconf openSUSE:Leap:42.2)

the goal 4 is actually already achieved. there are actually 9 pots generated from desktop files.

and the scripts are ugly and old - but their slowness is mainly because they have to go through packages in OBS one by one. So if you want this modern, you should start on OBS to offer a cross package build result like an on the fly generated tar */*desktopfiles

Created https://github.com/openSUSE/desktop-file-translations and moved the tools,pot and translations into it - removing from SVN and announced on opensuse-translations

I've opened a pull request for review. https://github.com/openSUSE/desktop-file-translations/pull/1

Stanislav, could you please add https://github.com/openSUSE/desktop-file-translations to l10n.o.o?

Example polkit file:
/usr/share/polkit-1/actions/org.freedesktop.policykit.policy

Example mime info:
/usr/share/mime/image/bmp.xml

Example Appdata:
/usr/share/appdata/firefox.appdata.xml

Everything should be done now, except for the point "make the mechanism more generic to also support polkit actions, appdata files and mime type information". I still have no idea what that actually means, the description is just too unspecific, and i'm getting the feeling that it might really be a different project that only slightly overlaps with this one.

My changes have been merged into the GitHub repo and the new workflow is explained here. I've also submitted an update to the desktop-translations package, which is now based on an _service file.

I gave you some examples of other files (that I know of) that may be installed along with the desktop files and also contain translations. The strings in those files may appear on the desktop too. You are now familiar with how the desktop file translation mechanism works. So you are qualified enough come up with suggestions how to deal with the other files. A naive solution would probably fork your code and run three more versions of it. Clearly undesirable. The tools you worked with do most of the work already. If they are generic enough adding at least one case of processing a different file type shouldn't be hard. If that's a separate project in your opinion, then make a plan of what would need to be done. I can't spoon feed that to you.

i.e. the first step is changing https://build.opensuse.org/package/view_file/openSUSE:Leap:42.3/update-desktop-files/brp-trim-desktop.sh?expand=1 to copy away these files to have them available in 42.3 for extracting.

But this only makes sense if we know that e.g. polkit can read from .mo files.

So, Ludwig, am i understanding you correctly that you want all strings with language code extracted from those additional file types, and merged with the rest of the data from the .desktop files? So everything ends up together in the same .po files in the Git repo? And that should be done by a new program replacing brp-trim-desktop.sh, with pluggable data extraction modules for different file types?

kraih wrote:

So, Ludwig, am i understanding you correctly that you want all strings with
language code extracted from those additional file types, and merged with the
rest of the data from the .desktop files? So everything ends up together in
the same .po files in the Git repo? And that should be done by a new program
replacing brp-trim-desktop.sh, with pluggable data extraction modules for
different file types?

Sounds like a possible solution.

The connection with Git and Weblate it the smaller part of the work. Translation mechanism of these files was not designed for ex-post translation updates, so it will need a significant amount of work to change it.

I can imagine three possible ways to fix it:

1. Use the SUSE desktop file approach: patch libraries and application accessing desktop files, to load external translations.

I am not sure how complicated it would be.

1. Use the way we used for lang packages in past:

Split out all these files to a separate sub-package.

Invent an update script creating lang bundles of updated files.

It would again require patching, now we have to patch search path for these files, exactly like we have a patch in the glibc modifying search path for translations.

1. Handle update on packaging level:

Again split out all these files to a separate sub-package.

But then invent a mechanism that picks the in-package files, processes them somehow, and creates an update package with a higher Release number. Possibly publish these packages in a separate repo.

Note: 1 and 2, as they exist currently for desktop files and language bundles, are not extensible. Only one directory and only one domain name can be used. => The mechanism is not usable for add-ons and third party packages.

I can imagine an alternative solution: Adding a TextDomain and TextDomainDir keywords. Then different packages can have different translation domain. (Normally, desktop translations remain in the po files that come with the package.)

Attached is a POC of a script that strips all xml:lang from mimetype info, appstream metainfo and polkit actions and collects it in build result files.
(It's all just xml, so I put it into a single script for now). It can be seen in action here:

https://build.opensuse.org/project/show/home:favogt:branches:X11:common:Factory

Now the scripts for generating .pot and .po files are missing and also support for gettext in polkit and appstream (-Qt, -glib).
I'm not sure which libs all read the mimeinfo xml, but it might be many different libs that need to be patched...

Attachments are apparently broken, so use the linked OBS prj for now to have a look.

I don't know polkit exactly, but I will prefer more generic solution.

Looking at a random polkit and MIME files, I see that both use similar syntax:

MPEG video
MPEG مرئي
Videa MPEG
Видео — MPEG

<message>Authentication is required to run a program as another user</message>
<message xml:lang="cs">Pro spuštění programu pod jiným uživatelem je vyžadováno ověření</message>

If we define a common way to support external translation, its support can be moved to a common library (libxml2?)

I can imagine:
MPEG video

<message xml:textdomain="suse-polkit-action">Authentication is required to run a program as another user</message>

To match gettext features, we should support xml:textdomaidir as well.

Something like that would be upstream-able, code could be common for many projects, and the only change needed by SUSE would be adding small change to XML generator. Even there would be possible to invent something that could be upstreamed, e. g. configure option --with-textdomain --with-textdomaindir --disable-embedded-translation, ideally as a part of some m4 macro set.

There is a one good reason, why embedded translation was invented: Desktop files come from different projects, each desktop file would have a different textdomain; many translation files have to be loaded just to display menu. My proposal would be a half way between both. It would be a bit more complicated to implement: As textdomain name is not hardcoded, it would require to keep list of textdomains that are already loaded.

By the way, normal gettext translation of projects not only hardcodes strings to XML or desktop files, but it also keeps them in the po file. So it could work out of the box with TextDomain=@GETTEXT_PACKAGE@