supporting file formats that have unique paths but duplicate file names

[eighthave]

Describe the problem

F-Droid repositories can include app translations. (fdroiddata is the internal name for the git repo format for managing an F-Droid repo.) It is inspired by the Fastlane layout, but includes multiple apps in one git repo. Currently, we have a hacky script that converts these files to XLIFF for Weblate to consume. We would like to be able to add fdroiddata git projects directly to Weblate, then use Weblate's support for submitting translations via pull requests.

@jspricke @linsui

Describe the solution you would like

@nijel what fdroiddata would need is a way to use the full path to represent the strings, e.g. metadata/*/en-US/summary.txt would be the source strings. Then the translations would be like:

metadata/eu.vranckaert.worktime/cs/summary.txt
metadata/eu.vranckaert.worktime/de/summary.txt
metadata/eu.vranckaert.worktime/en-US/summary.txt
metadata/eu.vranckaert.worktime/es/summary.txt
metadata/eu.vranckaert.worktime/fr/summary.txt
metadata/eu.vranckaert.worktime/he/summary.txt
metadata/eu.vranckaert.worktime/pl/summary.txt
metadata/eu.vranckaert.worktime/pt-BR/summary.txt
metadata/eu.vranckaert.worktime/pt-PT/summary.txt
metadata/eu.vranckaert.worktime/pt/summary.txt
metadata/eu.vranckaert.worktime/ro/summary.txt
metadata/eu.vranckaert.worktime/ru/summary.txt
metadata/eu.vranckaert.worktime/sq/summary.txt
metadata/eu.vranckaert.worktime/sw/summary.txt
metadata/eu.vranckaert.worktime/tr/summary.txt
metadata/eu.vranckaert.worktime/uk/summary.txt
metadata/eu.vranckaert.worktime/zh-CN/summary.txt
metadata/eu.wikijourney.wikijourney/de/summary.txt
metadata/eu.wikijourney.wikijourney/en-US/summary.txt
metadata/eu.wikijourney.wikijourney/es/summary.txt
metadata/eu.wikijourney.wikijourney/fr/summary.txt
metadata/eu.wikijourney.wikijourney/he/summary.txt
metadata/eu.wikijourney.wikijourney/nb/summary.txt
metadata/eu.wikijourney.wikijourney/pl/summary.txt
metadata/eu.wikijourney.wikijourney/pt-BR/summary.txt
metadata/eu.wikijourney.wikijourney/pt-PT/summary.txt
metadata/eu.wikijourney.wikijourney/pt/summary.txt
metadata/eu.wikijourney.wikijourney/ru/summary.txt
metadata/eu.wikijourney.wikijourney/tr/summary.txt
metadata/eu.wikijourney.wikijourney/uk/summary.txt
metadata/eu.wikijourney.wikijourney/zh-CN/summary.txt
metadata/eu.woju.android.packages.hud/cs/summary.txt
metadata/eu.woju.android.packages.hud/de/summary.txt
metadata/eu.woju.android.packages.hud/en-US/summary.txt
metadata/eu.woju.android.packages.hud/es/summary.txt
metadata/eu.woju.android.packages.hud/fr/summary.txt
metadata/eu.woju.android.packages.hud/he/summary.txt
metadata/eu.woju.android.packages.hud/is/summary.txt
metadata/eu.woju.android.packages.hud/pl/summary.txt
metadata/eu.woju.android.packages.hud/pt-BR/summary.txt
metadata/eu.woju.android.packages.hud/pt-PT/summary.txt
metadata/eu.woju.android.packages.hud/pt/summary.txt
metadata/eu.woju.android.packages.hud/ro/summary.txt
metadata/eu.woju.android.packages.hud/ru/summary.txt
metadata/eu.woju.android.packages.hud/sw/summary.txt
metadata/eu.woju.android.packages.hud/tr/summary.txt
metadata/eu.woju.android.packages.hud/uk/summary.txt
metadata/eu.woju.android.packages.hud/zh-CN/summary.txt
metadata/exa.lnx.a/ar/summary.txt
metadata/exa.lnx.a/ca/summary.txt
metadata/exa.lnx.a/cs/summary.txt
metadata/exa.lnx.a/de/summary.txt
metadata/exa.lnx.a/en-US/summary.txt
metadata/exa.lnx.a/eo/summary.txt
metadata/exa.lnx.a/es/summary.txt
metadata/exa.lnx.a/et/summary.txt
metadata/exa.lnx.a/fr/summary.txt

Describe alternatives you have considered

We tried to use the existing Fastlane support, which is similar, but that's not feasible because the Fastlane format is based on there only ever being one string file called short_description.txt, etc.

#12121

Is this feasible? If it is a big project, would you consider doing it as part of the funding proposal we're putting together?

Screenshots

No response

Additional context

No response

[nijel]

Is this really supposed to be a single translation component? Maybe component discovery would be a better approach to this. Or there is just summary.txt for each of these?

[jspricke]

Currently fdroiddata has almost 5000 apps and over 2600 have translated content, would you propose to generate 2600 components for those?

Or there is just summary.txt for each of these?

There are currently: summary.txt, description.txt, name.txt and some changelogs.

[nijel]

I didn't investigate the repository, so I just wanted to know how it looks. Having separate components when most of them will have just a few strings really doesn't sound like a good approach.

[eighthave]

The f-droid.org collection will be the largest by far. Most "fdroiddata" app repos would have more like 10-100 strings. So I agree, I don't think component discovery is the right approach here. So I guess mapping the string based on full file path isn't possible?