Translation of AppData files (reopening the discussion)
Hi all!
So there was this discussion #149 (closed) about whether or not to translate AppData file. And as I understand it, the conclusion (4 years ago) was that translating years of release notes was too much work for translators, especially for strings which are barely seen. I can completely understand this issue. No denying it is one.
As some mentioned in the same report, trying to revive the topic a few months ago, libadwaita now has an About dialog widget and various application installing software show the translated release notes (including GNOME Software). In GIMP, from GIMP 3 (this was already tested in several 2.99 development releases), we will have a welcome dialog, which also shows the release notes (translated if translations available). So we would really welcome having translations for our AppData file.
Now I think we could take care of the "translating old <release>
tags" issues by using attributes. When I look at the /usr/share/gettext/its/appdata.its
on my system, I see:
<its:translateRule selector="/component/name |
/component/summary |
/component/description |
/component/developer_name |
/component/name_variant_suffix |
/component/screenshots/screenshot/caption |
/component/releases/release/description |
/component/agreement/agreement_section/name |
/component/agreement/agreement_section/description"
translate="yes"/>
[…]
<its:translateRule selector="/component/releases/release/description[@translatable = 'no']"
translate="no"/>
It looks like it could be replaced by:
<its:translateRule selector="/component/name |
/component/summary |
/component/description |
/component/developer_name |
/component/name_variant_suffix |
/component/screenshots/screenshot/caption |
/component/releases/release/description[@translatable = 'yes'] |
/component/agreement/agreement_section/name |
/component/agreement/agreement_section/description"
translate="yes"/>
(and delete the last rule)
In other words, to start with, this should select only <release>
tags which explicitly added translatable='yes'
attribute (instead of the opposite and assuming that a release description is translatable by default). By default, <release>
description would not be translated. This should alleviate the issue of translators being suddenly buried under thousands of new strings when adding the AppData extraction (since I believe that most projects won't add the translatable='yes'
attribute explicitly.
Therefore we would add this attribute only to new <release>
tags, leaving older ones forever untranslated (we don't mind).
Now in #149 (closed), I believe the second issue which was raised was to leave enough time to translators, since some developers sometimes make release notes at the last second (I plead guilty too). So that makes for translations happening after the release, so the work of translators is not even showing up in the end. I agree it feels like a huge waste of translator time.
For this, first developers should be a little more thoughtful and we could come up with rules on "what is a good release notes" and "what is the minimum delay to give translators". For our <release>
descriptions, we try to just have a short introduction followed by a not-too-long list of items.
As for the delay, in the case of GIMP 3.0, we plan on having our string freeze around January (this will include the <release>
contents) for a release happening hopefully between April and May. See GNOME/gimp#10373.
For smaller releases afterwards, the delay between writing a <release>
tag and actual release would be shortened, but if we can come up with a good rule of thumb on how much minimum delay you need, we would work on following it. And if some times, we were to mess up (or needed to make an emergency release), we would simply not add the translatable='yes'
attribute. That's fine. This is actually the great advantage of translatability being opt-in for <release>
tags rather than opt-out, because then we make an informed choice when we actually ask the translation teams for a translation. We'd only do it when we know we give you enough time.
Last but not least, we could have an even more extreme appdata.its
with:
<its:translateRule selector="/component/name |
/component/summary |
/component/description |
/component/developer_name |
/component/name_variant_suffix |
/component/screenshots/screenshot/caption |
/component/releases/release[1]/description[@translatable = 'yes'] |
/component/agreement/agreement_section/name |
/component/agreement/agreement_section/description"
translate="yes"/>
What this does is that it only extracts the description of the last <release>
tag (note the [1]
added in the xpath), if and only if translatable="yes"
is set. I tested this xpath, with xmllint
at least, it works as expected.
This way, each time a new <release>
tag is added, previous ones are dropped, so that new languages (or translators trying to catch up on low translation rate case) don't get submerged by years of release notes to translate, once the new rule has been in place. Though having old release info translated is nice too, what matters the most is to inform people of the news in the new release they are testing, either through repositories/stores/installer software, or even in-application.
How does that sound? Could such an updated appdata.its
be put in place and a responsible procedure be agreed on between development and translation teams? Thanks!