Wrong language codes for gradle-play-publisher && f-droid

[rtsisyk]

Describe the issue

App store metadata files format uses wrong short two-letter language codes for gradle-play-publisher && F-Droid. For example, hu instead of hu-HU, de instead of de-DE and so on.

I already tried

• I've read and searched the documentation.
• I've searched for similar issues in this repository.

Steps to reproduce the behavior

No response

Expected behavior

Below is the correct list of language codes retrieved from Google Play:

"af",    # Afrikaans
"sq",    # Albanian
"am",    # Amharic
"ar",    # Arabic
"hy-AM", # Armenian
"az-AZ", # Azerbaijani
"bn-BD", # Bangla
"eu-ES", # Basque
"be",    # Belarusian
"bg",    # Bulgarian
"my-MM", # Burmese
"ca",    # Catalan
"zh-HK", # Chinese (Hong Kong)
"zh-CN", # Chinese (Simplified)
"zh-TW", # Chinese (Traditional)
"hr",    # Croatian
"cs-CZ", # Czech
"da-DK", # Danish
"nl-NL", # Dutch
"en-IN", # English
"en-SG", # English
"en-ZA", # English
"en-AU", # English (Australia)
"en-CA", # English (Canada)
"en-GB", # English (United Kingdom)
"en-US", # English (United States)
"et",    # Estonian
"fil",   # Filipino
"fi-FI", # Finnish
"fr-CA", # French (Canada)
"fr-FR", # French (France)
"gl-ES", # Galician
"ka-GE", # Georgian
"de-DE", # German
"el-GR", # Greek
"gu",    # Gujarati
"iw-IL", # Hebrew
"hi-IN", # Hindi
"hu-HU", # Hungarian
"is-IS", # Icelandic
"id",    # Indonesian
"it-IT", # Italian
"ja-JP", # Japanese
"kn-IN", # Kannada
"kk",    # Kazakh
"km-KH", # Khmer
"ko-KR", # Korean
"ky-KG", # Kyrgyz
"lo-LA", # Lao
"lv",    # Latvian
"lt",    # Lithuanian
"mk-MK", # Macedonian
"ms",    # Malay
"ms-MY", # Malay (Malaysia)
"ml-IN", # Malayalam
"mr-IN", # Marathi
"mn-MN", # Mongolian
"ne-NP", # Nepali
"no-NO", # Norwegian
"fa",    # Persian
"fa-AE", # Persian
"fa-AF", # Persian
"fa-IR", # Persian
"pl-PL", # Polish
"pt-BR", # Portuguese (Brazil)
"pt-PT", # Portuguese (Portugal)
"pa",    # Punjabi
"ro",    # Romanian
"rm",    # Romansh
"ru-RU", # Russian
"sr",    # Serbian
"si-LK", # Sinhala
"sk",    # Slovak
"sl",    # Slovenian
"es-419", # Spanish (Latin America)
"es-ES", # Spanish (Spain)
"es-US", # Spanish (United States)
"sw",    # Swahili
"sv-SE", # Swedish
"ta-IN", # Tamil
"te-IN", # Telugu
"th",    # Thai
"tr-TR", # Turkish
"uk",    # Ukrainian
"ur",    # Urdu
"vi",    # Vietnamese
"zu",    # Zulu

Screenshots

No response

Exception traceback

No response

How do you run Weblate?

weblate.org service

Weblate versions

No response

Weblate deploy checks

No response

Additional context

No response

[nijel]

The issue with this is that the same code is used for both Google and Apple. Unfortunately, they don't agree on them. See #5522 (comment) (and whole issue for discussion between @eighthave and @spacecowboy on this).

Maybe documenting the best practice would be the way to go? Or should Weblate have separate flavors for Apple and Google?

[rtsisyk]

The issue with this is that the same code is used for both Google and Apple. Unfortunately, they don't agree on them. See #5522 (comment) (and whole issue for discussion between @eighthave and @spacecowboy on this).

I don't agree in them either, but this is real situation on the ground :(

Maybe documenting the best practice would be the way to go?

Is it possible to set language code manually? I've renamed hu to hu-HU in git, but even after that Weblate continued to contribute changes to hu folder.

Or should Weblate have separate flavors for Apple and Google?

This is a good question. I guess that fastlane uses the same structure both for Apple and Google, but I am not 100% sure.

[eighthave]

I think the best way to handle it is the consuming tool (e.g. Fastlane, fdroid update, etc) should implement a linter that warns the user about invalid locales. fdroid update supports all valid BCP47 locale tags. From what I've seen Weblate also supports all valid BCP47 locale tags. Fastlane is a tool to upload to Google Play and Apple App Store, I think it already has linters for those two cases. If Triple-T Gradle Play Publisher does not have a linter for this, implementing one there sounds like the right solution to this problem.

[nijel]

I've renamed hu to hu-HU in git, but even after that Weblate continued to contribute changes to hu folder.

This should work, just make sure you commit any pending changes in Weblate before renaming. Otherwise, it might happen that pending change Weblate creates another file in the hu folder and your renaming to hu-HU won't cause conflict because Git operates on files level, not on folders. Then you would end up with both folders (and Weblate complaining about duplicate translation).

[spacecowboy]

The issue with this is that the same code is used for both Google and Apple. Unfortunately, they don't agree on them. See #5522 (comment) (and whole issue for discussion between @eighthave and @spacecowboy on this).

Maybe documenting the best practice would be the way to go? Or should Weblate have separate flavors for Apple and Google?

What I have done is

• freeze weblate project for maintanance
• Edit the repo and correclty name the directories
• Force weblate to reset to current master
• Re-enable weblate

This will fix the problem. Until some dude shows up and creates a new translation which gets a bad code. Then it's the same procedure again. It sucks but once people have created the languages you don't have to do it again.

I can also recommend using validate_deploy with fastlane in CI. That's how I become aware of these issues BEFORE I want to release the app.

I've also used scripts that delete certain unsupported languages before running a release.

[rtsisyk]

What I have done is

freeze weblate project for maintanance
Edit the repo and correclty name the directories
Force weblate to reset to current master
Re-enable weblate

This is what I do every time when somebody adds a new language...

[nijel]

Okay, let's add separate naming for Apple App Store and Google Play.

[github-actions]

Thank you for your report; the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.

[eighthave]

@nijel nijel closed this as completed in c6a660a

I would recommend putting this link next to the GOOGLEPLAY_CODES entry in the code. They regularly make changes to the list, and don't seem to follow any pattern of when they include the country in the locale tag, and when they leave it out.
https://support.google.com/googleplay/android-developer/answer/9844778

I can also recommend using validate_deploy with fastlane in CI. That's how I become aware of these issues BEFORE I want to release the app.

Could you point me to a project where you have that setup? Sounds quite useful.

[rtsisyk]

Thanks a lot!

[spacecowboy]

Could you point me to a project where you have that setup? Sounds quite useful.

@eighthave On this line here: https://gitlab.com/spacecowboy/Feeder/-/blob/master/fastlane/Fastfile#L67

[rtsisyk]

When do we expect to see this change on hosted.weblate.org? I want to try.

[nijel]

It is already there.

[spacecowboy]

No it isn't @nijel . Still only the old App Store Metadata files option. (The dropdown list refuses to be caught by the screenshot)

Edit: Aha, it's at the very bottom!

Also btw, why are the dropdown lists not sorted alphabetically?

[nijel]

Also btw, why are the dropdown lists not sorted alphabetically?

Because nobody considered it here. Fixed in 6541cad