automatically test for missing string documentation #6485
Description
What is the user problem or growth opportunity you want to see solved?
This is a follow-up to #6457. I'm close to completing the documentation of all the strings. After that is done, the automatic should test should prevent adding translatable strings that aren't properly documented in values-qq/strings.xml. This is already done in MediaWiki and extension using the banana-checker library. As far as I can tell, it is also done in the Wikipedia Android app.
How do you know that this problem exists today? Why is this important?
This is a problem because translators often don't know how to translate something. While I was writing the documentation for all the strings in the last few days, for example, I found many strings that translators (including myself!) misunderstood and translated incorrectly. I corrected them wherever I could, but there are possibly still some mistakes in other languages. And of course, the likelihood of these misunderstandings should be lowered going forward.
You can read more at #6457 and at https://www.mediawiki.org/wiki/Help:System_message#Message_documentation .
Who will benefit from it?
Three groups, in no particular order:
- Volunteer translators on translatewiki: It will be easier for them to understand the context and the function of the string and make a correct translation.
- App developers: They'll also be able to see the context and the meaning of the string more easily while they are reviewing code, fixing bugs, and adding features.
- End users in all languages: They will get more translations that are more likely to be correct.
Anything else you would like to add?
This is already done in the Wikipedia Android app. I found these, although I haven't yet explored the code deeply:
- https://github.com/wikimedia/apps-android-wikipedia/blob/main/scripts/missing-qq.py
- https://github.com/wikimedia/apps-android-wikipedia/blob/main/.github/workflows/android.yml (search for qq).
Perhaps this could be adapted to the Commons app. This would be good not only because it (possibly) requires less coding, but because it also promotes uniform practices across Wikimedia-related apps.
Another option is to integrate something that does this into the Commons app's own Gradle build configuration.
I'm not an expert on GitHub workflows and Gradle, so opinions are welcome.