support Google Play upload tools: Fastlane and Triple-T Gradle Play Publisher

[eighthave]

There are two major tools for managing the localized files for Google Play: Fastlane Supply and Triple-T Gradle Play Publisher. F-Droid also supports the same file/dir structure. If Weblate would directly support those files, then there would be a clean, simple, automated way to translate Android apps using Weblate. Here's the ideal workflow:

1. Weblate pulls source from git
2. translators work in Weblate
3. translations get pulled into app's source directly where Fastlane or Triple-T expect them
4. F-Droid automatically uses those translations from git
5. those translations are directly published to Google Play via the respective tool (Fastlane Supply or Gradle)

Both Fastlane and Triple-T use plain text for the source and translation file format. title and short_description would be easy to support directly as plain text, changelog and full_description much less so:

• title: 30 char limit, one line, plain text
• short_description: 80 char limit, one line, plain text
• full_description: 4000 char limit, multiple lines, can contain basic HTML
• changelog: 500 char limit, multiple lines, plain text

But perhaps this setup is just too different from standard translation workflows that assume strings are in a single source file. I've also opened issues on those tools to get feedback there:

• Triple-T/gradle-play-publisher#227
• fastlane/fastlane#9520

I really want to find a way to get this workflow working really smoothly. Translations are really important, and something that really should be as automated as possible.

[eighthave]

Here's one hard part of this whole setup: the hard character limits for full_description and changelog. So 4000 and 500 chars are pretty big blocks of text for a single translation string. But I haven't found a way to set a character limit for a group of strings, only for a single string.

[azachar]

Hello, is here any progress?

[nijel]

AFAIK nobody is working on this right now.

[eighthave]

I applied for a small grant to fund work on this, and related issues. Wish me luck :) I'll let you know.

[PanderMusubi]

Any luck with that grant proposal?

[eighthave]

yeah, I got a small grant to work on this, so I should be able to get
something done.

[eighthave]

And finally the grant is started! This is one of the tasks for the grant.

Also, I wanted to point out that Triple-T seems to be implementing an XLIFF-based solution, which would be ideal: Triple-T/gradle-play-publisher#227 I think we should help them with that goal where we can, since using XLIFF will provide lots of benefits.

@Matrixcoffee

[nijel]

The basic implementation has just landed in our repo, there still are some rough edges and missing features, but the basics should work:

• It parses title, short_description, full_description, changelogs and video files, setting proper length and flags for those
• Every file is presented as single string in Weblate (see below)
• The discovery should find the correct component configuration
• Support for changelogs still needs to be implemented

I originally wanted to have long descriptions split, but in the end it's not there for following reasons:

• Lot of files seems to wrap paragraphs, what would lead to splitting real paragraphs into more strings, what would probably lead to weird translations
• The split strings would lead to question what to write into the file if only some of the strings are translated
• The maximal length check would become tricky (and especially tricky to present it reasonably to user)
• Weblate should be clever enough to detect changes in the source string and present those to user

It needs some more testing before it can be deployed (I will get to that later this week), but any feedback is welcome.

[janpio]

Could you create an issue over at fastlane and mention me? Then I can investigate at the fastlane codebase a bit and not spam all the other people here ;) Thanks.

[eighthave]

Two small bug reports after using this for a bit:

• The character counts are wrong for at least some strings. For example, an English changelog file that is 498 bytes on disk and wc --chars says 498 characters is showing up in Weblate as 519 characters. https://hosted.weblate.org/translate/f-droid/f-droid-metadata/ru/?checksum=1ed204482ed782d6#comments

• commit 9e338694a46f248ad259fb4f4dce4c1f0342cb0a in f-droid/f-droid-metadata has come back after I removed it and force-reset Weblate on the upstream git repo. It is deleting most of the source strings. I asked @comradekingu if he knew why, since it shows as his commit, and he wasn't sure.

[nijel]

The 500 chars limit for translation is not coming from string length, but is hardcoded based on your initial comment in this issue. And I have no clue how somebody came to 519 chars...

If that limit is wrong it can be certainly changed. This again opens up same question: is there some specification for all this, or it's just randomly placed text files with random semantics depending on used tools?

[nijel]

And the commit is from Fri Feb 15, so it probably was not removed on Weblate side? Are you sure it was removed from upstream repo when doing reset on Weblate side?

[eighthave]

• I'm sure about those character limits, that's what we implemented in F-Droid after lots of research. I can dig up the references if you need them. I asked the translator where they got the 519 number from.

• About the 9e338694a46f248ad259fb4f4dce4c1f0342cb0a commit, I made a local branch of the commits I got from weblate, then removed the commit that removed the source strings, then merged that into our repo. Then I went to the Weblate Repository Maintenance web interface and clicked on "Reset".

[nijel]

I guess the 519 counts whitespace chars indicated by Weblate. But still the problem is that there is (nearly) 500 chars string which is supposed to be translated into 500 chars, what is not really easy for many languages.

I've reproduced the issue with wiping strings locally, working on a fix.

[nijel]

I've just deployed new version which should not produce such commits.

[comradekingu]

@nijel You get to 519 by copying the source string with the button, that way you get the same number as the source to work with.
Some of the strings 1, 2 and 3 are empty.
It seems like 1 and 2 weren't meant to be, as they previously had content that isn't found in other strings.

[nijel]

That's caused by bug discussed above, I've just discarded broken commits and forced update, should be fixed now.

[comradekingu]

@nijel Now none of the strings are corrected though. Is it safe to edit them in Weblate?

[nijel]

Yes, it should be safe now (it discarded changelog edits, sorry).

[nijel]

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

• In case you see problem with the fix, please comment on this issue.
• In case you see similar problem, please open separate issue.
• If you are happy with the outcome, consider supporting Weblate by donating.

[cetti]

@eighthave where did the grant come from?

[eighthave]

https://www.iscproject.org/