Automatically screenshot each screen, annotate English strings, and upload to Weblate for translation context.
In response to the post about streamlining the translation process, @eighthave suggested I post my suggestion as an issue. fdroidclient may not be the right repo for this, as it may actually end up as a new project if it is undertaken.
Problem: When using Weblate to translate English strings from F-Droid client, you are not provided any context about how a particular English string is actually used within the app.
Solution: Automatically scrape F-Droid, taking screenshots of each string, then annotate the screenshots where strings are found and uploading to Weblate for context.
I have a (very) initial proof of concept available in pserwylo/annotate-android-strings. Doesn't do any of the hard stuff yet, it is just a script I started working on a couple of years ago then forgot about.
I think this can be done by:
- Using an espresso test to visit each page of F-Droid which contains strings.
- For each screen:
- Take a screenshot using
adb shell screencap
. - Using
adb shell uiautomator dump
to get the UI hierarchy in an XML format. - Parse XML to look for any text, and for each string found:
- Grep the English
strings.xml
to look for the corresponding<string>
"name". - Look in the XML in order to find out the location of the text in the screenshot?
-
Use imagemagick to draw a box around the text, and also overlay the strings name (e.g.
@string/app_name
).
- Grep the English
- Automatically upload the resulting annotated image to Weblate using the screenshots API
- Take a screenshot using
The tricky bit will be finding strings which have positional arguments, but there are probably creative ways to grep which will find matching strings. For example, instead of grepping strings.xml
for each string we found in the uiautomator dump
, do it the otherway around and grep the output of uiautomator dump
for each string (but use wildcards where the positional arguments are).
The reason I think this is of high value, is because it is a pretty generic workflow that has very little (if any) dependency on F-Droid specifically, and other Android apps could benefit from the exact same tooling.