Rename all fastlane directories to a country specific code

[Poussinou]

Hi,

Would it be possible to rename the directories from fastlane to a country specific code? That's the only solution to make it works. We had a discussion about this here

For example, en directory should be renamed to en-US (this one will be the reference, so this is where the screenshots should be, and that's already the case 😃 ) or fr to fr-FR. You could have a look at this repo and this Wikipédia page to know the right name of the directory.

This enhancements would allow F-Droid users to have some nice screenshots the next time you tag a new release :)

Ask if you have any question 👍

[westnordost]

Hmm, wouldn't it be better if it was implemented on F-Droid side to also understand and fall back to language-only directory names?

What about if the F-Droid user's locale is on es-AR but this (or any other project) only has a directory named es-ES?

[Poussinou]

I believe the F-Droid core team wants to use the fastlane directories (including images) directly in the app repos, like this one, to reduce the stress on this F-Droid data repo (Already more than 48000 commits). Removing images (or avoiding adding new ones) from/to this repo would be very helpful to reduce his already-very-large size.

Regarding your question about es-AR and es-ES locals, this is well handled by Android : The most important of the local being the es, the es-AR user will automatically see the es-ES local.

Here is the list of locals supported by fastlane. As you can see there's no support for an en local, the most important one being the en-US. If a F-Droid user only has en local enabled, he will see the en-US local. Other locals note listed here can be kept for convenience, but they probably won't show up in the F-Droid client (I'm not sure about this, to be honest, maybe they will be shown).

[westnordost]

I do not understand what what fastlane supports has to do with this. I thought F-Droid is just using the directory structure as generated by fastlane or alternatively the directory structure as generated by Triple-T.

The directories created by fastlane also are quite inconsistent, some are of the format de-DE, some of the format ru. fastlane is geared towards the (Apple) App Store which only supports very few countries - those in which they sell iPhones. A limitation to such few countries is completely unnecessary for a FOSS project like F-Droid.

If the directory selection was handled by Android the same way localized resources are handled by Android, then it wouldn't be a problem because it is perfectly fine to have e.g. a strings.xml for es and one for es-AR.

Can you perhaps point me to the code? I might create a PR to fix the directory selection.

[rugk]

Might this discussion not basically better be done in the FDroid issue tracker or so?

[Poussinou]

@westnordost Yes you're right, F-Droid just use the fastlane directory structure, but I though that keeping a directory structure that complies with the official Fastlane structure would allow you to use it everywhere (including the Google Play Store) and keep everything clean and simple, but as you want. And yes, other locals are inconsistent I agree with you.

My proposition was based on the observation that the screenshots are available trough the android client and the website with repos like this one who are using the "official" en-US local. I can't understand why it doesn't work with a simple en local. I'm sot sure anymore on how it works, by the way.

I couldn't find the right file where the fastlane metadata are handled in F-Droid repos. Maybe we should ask them, like rugk said.

[westnordost]

Ah, I thought you are from the F-Droid project. Well yes, it would make sense to open up a ticket there.

[Poussinou]

I contribute to the F-Droid project and I have some right access on 2 repos, but I do not consider myself as a core-team member, and I surely didn't wrote the python script that parse fastlane directories...

[westnordost]

So it is not the app itself who reads the fastlane directories but the server, I did not know that.

[Poussinou]

I think this is the server, but I'm not totally sure, since I wasn't involved in this new feature at all...

We really should ask, it'll be interesting. Do you want to open the Issue with all your questions by yourself, since you're more technical than me? I'm just a simple contributor, and I'm new to Android programming and things like Fastlane. Otherwise I'll do it.

PS : Sorry to bother you with all this and my inexperience.

[westnordost]

I think it is better if you opened a ticket because you have a better overview over the different projects within the F-Droid sphere.

[westnordost]

@Poussinou Did you open a ticket somewhere? If yes, can you paste the link here?

[PanderMusubi]

About F-Droid being able to use the content of fastlane, the repo of StreetComplete needs to offer fastlane in a certain format. The F-Droid repo does not need to contain any info on this, it prefers that all is (in the tagged releases) in the repo here.

A working example is:

• https://github.com/vanilla-music/vanilla/tree/master/fastlane/metadata/en-US/images (here is where featureGraphic.png is expected to be)
• https://github.com/vanilla-music/vanilla/tree/master/fastlane/metadata/en-US/phoneScreenshots (here is where screenshots are expected to be, filenames not important)

As you can see, https://github.com/westnordost/StreetComplete/tree/master/fastlane/metadata/android/en/images is not organized exactly like that. does this help getting this fixed for StreetComplete?

[westnordost]

@Poussinou ping

[westnordost]

I created an issue myself now https://gitlab.com/fdroid/fdroidserver/issues/621

[westnordost]

And fixed in https://gitlab.com/fdroid/fdroidserver/merge_requests/611

While reading through the code, I also found out that the metadata is also searched for in /metadata/, so I changed it because it's shorter and I do not use fastlane.