After D the translations live in a git submodule, and F-Droid doesn't fetch submodules unless the build recipe says so. I checked, and ours currently doesn't.
https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/at.bitfire.davdroid.yml?ref_type=heads
submodules: true was set on every build up to 4.3.4.1-ose and then dropped from 4.3.5-ose onwards - prob when the old cert4android/ical4android/vcard4android submodules were replaced by Gradle dependencies. The current entry (4.5.19) only has subdir, gradle and prebuild.
What the flag does, per the build metadata reference: "causes git submodule update --init --recursive to be executed after the source is cloned".
Note it's a merge request on GitLab, not a GitHub PR, and we don't control the review speed - that's why this should be done with prio.
After D the translations live in a git submodule, and F-Droid doesn't fetch submodules unless the build recipe says so. I checked, and ours currently doesn't.
https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/at.bitfire.davdroid.yml?ref_type=heads
submodules: truewas set on every build up to4.3.4.1-oseand then dropped from4.3.5-oseonwards - prob when the old cert4android/ical4android/vcard4android submodules were replaced by Gradle dependencies. The current entry (4.5.19) only hassubdir,gradleandprebuild.What the flag does, per the build metadata reference: "causes
git submodule update --init --recursiveto be executed after the source is cloned".Note it's a merge request on GitLab, not a GitHub PR, and we don't control the review speed - that's why this should be done with prio.
fdroiddataaddingsubmodules: trueto the latest build entry inmetadata/at.bitfire.davdroid.yml. Worth explaining in the MR that an upcoming release adds a translations submodule and we want the autoupdate template to carry the flag - at the current commit there are no submodules, so it's a harmless no-op until D lands.davx5-translationsis public - F-Droid clones anonymously