i18n: Indirect string-array declarations through arrays.xml

[acolomb]

This fixes missing strings in Weblate translation, although they are supposedly in the strings.xml files.

Introduce string-array elements matching those from the source strings.xml, but instead pointing to a @string reference. The latter is to be translated based on the assigned sub item's key.

Weblate does not handle string-arrays, but needs this indirection, see https://docs.weblate.org/en/latest/formats/android.html

All existing translations are pulled in by migrating the <string-array name="..."><item>... elements to <string name="..."> elements instead. This was done using an XSLT stylesheet, so can be easily reproduced.

IMPORTANT, MERGING ORDER:

1. [x] The automated Weblate PR should be merged first, after committing any outstanding translation changes on Weblate.
2. [x] Then rebase this branch, best re-applying the XSLT in case of conflicts.
3. [ ] Then merge this PR.

[acolomb]

Note that these strings within string-arrays are not actually found on Weblate for translation currently.

CC @Catfriend1, I can apply the same logic to the fork. Will just see through it being merged here, then make a separate PR for you, replicating the change.

[imsodin]

Puh I got lucky, I merged the weblate update PR before checking this PR - which apparently was a/the right thing to do.

[acolomb]

@imsodin Would be good if we can merge this soon, before any more conflicts with incoming Weblate changes pop up. I have locked the Weblate component in the mean time, but would like to end that state ASAP.

[acolomb]

Using a separate release branch complicates the Weblate integration though. Because Weblate always bases its changes on the on the main branch. So if you merge weblate, you'll get these feature commits as well. If you don't, updated translations are not included. Might want to cherry-pick (and squash) the translation commits to release then.

This change in itself was kind of special, because it is exactly intended to allow more strings to be translated, while ramping toward the release.

[imsodin]

This commit doesn't change anything in translations, right? So I don't need it for the release. And I assume weblate only cares about main, so what I do on release shouldn't interfere with it, right?
The point of the separate release branch is to be able to merge this (and other PRs) into main, but not include them in the release as they are not part of the RC and thus not tested.

[acolomb]

Yes, the translations are untouched, but it enables these strings to be edited on Weblate at all.

Okay, so we have a different understanding about the rc status. I thought that translation updates should be possible between rc and final release, because translators need time after a feature is merged (often right before rc) and the app being frozen for release. Stopping translation merges after declaring an rc will also freeze the translations, so the final version might miss out on them and contain only English text for new strings / no improvements made in the meantime.

[imsodin]

Right. I just assumed that translations would take much longer than 1 week on average so a one week delay hardly matters. For the usual case where release and main don't diverge, it's not an issue - I can just merge weblate before the release. And if there's new translation strings I'll try to remember to cherry-pick if they (need to) diverge.