Comment 13 for bug 1927149
Revision history for this message
| Gunnar Hjalmarsson (gunnarhj) wrote | #13 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
On 2021-09-20 04:14, Matthias Klumpp wrote:
> I still think this is a dumb fix, especially since you loose the
> feature to actually mark strings from being untranslatable by
> dropping the appstream dependency.
And I still don't understand that part of your reasoning.
If appstreams's version of metainfo.its is not present when the POT file is generated, it falls back to gettext's version which does not extract <release/> strings at all. And that's what we want to achieve in Ubuntu, at least as long as GNOME keeps appstream's metainfo.its away when generating the upstream POT file. Did you see this issue:
https:/
> A proper workaround would be to leave that in, possibly backport the
> ITS patch for appstream to update the file, and then mark the release
> entries you don't want to have translated with `translate="no"` in
> the XML.
That's a possible way to deal with it in the future once the GNOME Software maintainer (and all other GNOME project maintainers...) have reached an agreement with the Damned Lies admins on the matter.
Please note that several `translatable="no"` have already been added:
https:/
(seems to be effective only for GNOME 41) But the <release/> strings for 40+ are still translatable, so even if the problem is reduced compared to when I first filed this bug report, it's still present.
If the Damned Lies admins would change their mind, we still have the problem with the very latest <release/> info. Let's study the release of gnome-software 40.4 as an example. The NEWS file and the appdata.xml file were updated in the same commit (surprise, surprise) on August 13:
https:/
The actual release HAPPENED ON THE SAME DAY!! So even if those strings had been passed to the GNOME translators via Damned Lies, the strings for 40.4 would still have been shipped untranslated. You can't just snap your fingers to have strings translated. Translators need time.
As you already know, I think it was an unfortunate mistake to consider the <release/> strings translatable by default. If some project owners wanted them to be translatable, it would have been much better to give those projects a possibility to opt in for translation. The maintainers of projects which opted in could be assumed to be aware of the required translation workflow for this to make sense.