integrating with Continuous Translation tools like Weblate, Transifex, etc.

[eighthave]

We've been using Weblate and Transifex to work with translators for our app strings for years now. It can really make it dead simple to work with translators in many languages. We've also been trying out techniques for doing the same with the app store descriptive materials, like what Fastlane manages. The big problem is that the Fastlane file layout is quite difficult to integrate with translation tools:

• they expect a single file for source strings (not title.txt, full_description.txt, short_description.txt, etc.)
• they work much better with real file formats like .po .xliff .json .yaml .xml rather than unstructured plain text
• char limits, notes to translators, etc. need to be in the source file (e.g .xliff)

Have there been any thoughts about how to integrate with standard translation workflows like these? What are people using for translation when using Fastlane?

So far, the best "solution" I've seen feels like a workaround: managing the translations in a separate tree of XLIFF files, then having those files converted using a plugin:
https://github.com/danielkiedrowski/fastlane-plugin-onesky

[fastlane-bot]

It seems like you have not included the output of fastlane env

To make it easier for us help you resolve this issue, please update the issue to include the output of fastlane env 👍

[mpirri]

Thanks for your feedback about this! What is it specifically about the onesky plugin that makes it feel like a workaround? Do you have a sense of what your ideal workflow would look like for this?

[eighthave]

The plugin workflow means that there two sets of files to maintain:

• localizations/*.xliff
• metadata/<locale>/*.txt

I suppose it would be OK if the *.txt files were entirely hidden from the developer, except for maybe entries in .gitignore. Also, XLIFF makes it easy to break up the long description into manageable chunks, but those chunks then need to be reassembled to make the .txt file. That logic will be custom to the plugin and perhaps even to the developer. So the developer has to be aware of the formats.

I outlined my ideal workflow in WeblateOrg/weblate#1525:

1. Weblate pulls source from git
2. translators work in Weblate
3. translations get pulled into app's source directly where Fastlane expects them
4. those translations are directly published to Google Play by Fastlane
5. F-Droid automatically uses those translations from git

[mpirri]

Regarding your first point - it does feel like you'd want to use the .xliff files as the "source of truth" and then dynamically build the fastlane metadata files from that.

Anyhow, this workflow does sound great. Unfortunately it isn't really something the core fastlane team can work on right now. It would be an amazing fastlane plugin, though. Any chance we could convince you to take a crack at building something like this? 😄

Thanks so much for the consideration, and I'm sorry I don't have better news for you. 🚀

[eighthave]

Upon thinking about this a bit more, the issue really is how to represent this to the fastlane user. Right now, the docs point to the text files, e.g. _metadata/en-US/full_description.txt_, as the place for the developer to manage their texts. With the plugin managing a separate file tree of XLIFF files, then the story becomes more like "well, sometimes there will be another set of files and those files will actually be the canonical ones". One easy way to deal with that is just have the files right next to the standard fastlane location, e.g. _metadata/en-US/full_description.xliff_, that would at least be easily visible to someone following the docs. The downside with that is that there are multiple .xliff files that serve as the source (title, short description, full description, changelogs), and lots of translations systems assume a single file per-language. I'm happy to try my hand at writing a plugin for this, once I figure out the right setup and user experience. So I'm mostly looking for feedback at this point.

[tobiasKaminsky]

We are also stumbled about this problem. Would be great if there will be a solution 👍
I can help you with testing @eighthave

[janpio]

Wouldn't it be enough to add a "DO_NOT_EDIT_FILES_BUT_READ_THIS.txt" into the metadata folder that explains that these files are generated automatically when using fastlane automatically by a plugin (and list exactly which ones)? The "handling" of the data from truth to fastlane structure will all be done by a plugin or via actions in a lane, right?

[fastlane-bot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest fastlane version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[fastlane-bot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest fastlane version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[tobiasKaminsky]

A real decent plugin which supports transifex -> fastlane would indeed be great and therefore I hope that this issue can remain open as an enhancement proposal
(this does not mean that the devs have to do it, but maybe there will be an user contribution)