Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow language mapping for Google Play resources #1149

Open
keunes opened this issue Nov 10, 2024 · 3 comments
Open

Allow language mapping for Google Play resources #1149

keunes opened this issue Nov 10, 2024 · 3 comments
Labels
dontclose Prevents the stale bot from closing this issue/pr enhancement Indicates new feature requests

Comments

@keunes
Copy link

keunes commented Nov 10, 2024

Problem description

Because of the above, we have to manually maintain the languages for all components (website has 4, play store listing 3, and the app itself 1). That's a bit of a pain.

Potential solutions/workarounds

Allow to provide a language mapping, or have such mapping built in. For example:

  • if language source file exists without region indication, and Google Play expects one with region
    • Example 1: we have resources in bn (may be used both in Bangladesh & India). Gradle play publisher takes this content and provides it to Google with the code bn_BD.
    • Example 2: one might have translations in pt (again, without region). Gradle play publisher takes this and provides it to Google both with the codes pt_PT and pt_BR
  • exact matches (with/without region) are taken as such
  • if language source file exists with region indication, and Google Play expects without region, then it strips the region code
    • Example: source material in lt_LT, Grade play publisher takes this and provides it as lt to Google
  • for cases with multiple matches, the user can indicate a mapping via some setting.
    • Example: ro_RO and ro_BG exist, and Google expects ro, then the user must indicate which resource is used to provided as ro or an error will be returned. (Bad example, just to show the point. Not sure if needed, given it's probably an unlikely scenario)
  • for languages (& regions) that Google doesn't support, nothing is submitted (e.g. eo)

Additional context

I realise that this would be Triple-T covering for Googles weird stuff. But it would be dam handy :-)

@keunes keunes added the enhancement Indicates new feature requests label Nov 10, 2024
@SUPERCILEX
Copy link
Collaborator

If you implement something and want to send a PR I consider accepting it, but honestly the behavior you're looking for might be best implemented with a preprocessing step you build in house as it seems pretty custom.

@SUPERCILEX SUPERCILEX added the dontclose Prevents the stale bot from closing this issue/pr label Nov 11, 2024
@keunes
Copy link
Author

keunes commented Nov 11, 2024

Thanks for the quick reply @SUPERCILEX

it seems pretty custom

I'm not sure if it's really that custom: the fact that Android holds different resource expectations (prefer without region) than Google Play store (very specific list, often with region) applies to all apps that publish to the Play store. And thus it applies to all users of Gradle play publisher. Or am I missing something here?

the behavior you're looking for might be best implemented with a preprocessing step you build in house

We're not entirely sure how this would work (what you had in mind). We're currently just manually running ./gradlew publishListing which takes the files to push content to Google Play.

We'd rather not adjust the file structure just for the Play store (we also publish to F-Droid and we're not sure if changing the structure would create issues), or work on different branches with (several) conversion steps (we've done that for our website and it created a monstrosity).

@SUPERCILEX
Copy link
Collaborator

I think that's fair, I'd be happy to accept a PR then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dontclose Prevents the stale bot from closing this issue/pr enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

2 participants