Android Target Bundle Using VCS Integration (GitHub)

I’m having some trouble with a CrowdIn workflow I’m trying to finalise for a mobile app project. The CrowdIn project that I’ve set up, is intended for providing localizations for an Android and iOS app. :iphone:

I’ve recently put together a workflow that enables our Design Team :art: to push source string changes through to CrowdIn using the Figma plugin. All strings that are uploaded are added to a Strings Vault file (.csv) in the Sources section of our project. This part works wonderfully. :sparkles: All required source strings end up in our CrowdIn project, including context, labels, etc. and can be translated into the target languages without issue. :raised_hands:

In order to get our translation changes pushed through to our Android and iOS codebases, I have added the GitHub VCS integration to our CrowdIn project and have configured it to use the “Target file bundles mode” to enable me to export Android XML and iOS Strings format files and push them to the appropriate codebases. Again, this works great… Except for one thing (and I hope that I’m simply missing something obvious):

The “Resulting file pattern” field of the “Branch Configuration” for my Android target file bundle doesn’t seem to have a way for me to remove or omit the -en from the end of the values-en export directory. Android treats the values directory as the default language, which in my case, is English (as is, our source language in our CrowdIn project).

Here’s a screenshot of where I got a bit stuck: :thinking:

I’ve tried working with different placeholders, like %android_code%, %two_letters_code%, etc. with no success. The closest I managed to get was using %two_letters_code%, but the -en predicament remained.

I then tried overriding the “English” language in the project’s “Language Mapping” section (in “Settings” > “Languages”) to try and make the English language placeholder for %android_code% return an empty value, but the Language Mapping UI wouldn’t let me do that. So I then tried the following:

Finally, using this rather hacky method, I managed to get the output that I required (and I’d imagine everyone(?) using Bundles via VCS integration for managing their localizations). :confetti_ball:

Long-winded post, though I want it to be easily searchable :mag: for those who are encountering the same issue. I spent more time than I’d have liked to, on finding this method of achieving the desired output. :pray:

Is there a better way to achieve this output, that I’ve completely missed? I’ve pored over countless CrowdIn articles, blogs, guides, forums, docs, code, third-party guides, videos, etc. and managed to turn up nothing that worked. :face_with_spiral_eyes:

1 Like

Hello @forcite

Must say, a great setup :astonished:

The basic workflow (at least, this is the most common one) is to upload iOS or Android as a source or use both of them with a unified placeholder option. And Figma receives translation from TM pre-translate.

But your workflow looks great to me, and there’s nothing I can add at this moment. The only thing, maybe, will be related to the project itself. From my database, I can see that you have English as both source and target language. Can you please clarify the need for it? Is it something you need for internal purposes?

If you remove English from targets, values-en (the folder for English translation) will be removed as well.

1 Like

Thanks @Dima :muscle: so far it’s working well! :pray:

You’ve actually touched on an improvement I intend to make, once we’ve bumped up our CrowdIn subscription plan, to include custom workflows! :gear: I’d like to add an automated pre-translation step that uses both Translation Memory :brain: and the Machine Translation :robot: engine to seed translations (as outlined in this support article) as soon as a change has been made on Figma and pushed up to CrowdIn. :ok_hand: I can imagine that this will reduce the initial (manual) translation step of our localization workflow.

“From my database, I can see that you have English as both source and target language. Can you please clarify the need for it? Is it something you need for internal purposes?” - @Dima

This actually relates to something that had me a little unsure :thought_balloon: during the design of this localization workflow! I found that in the past, I needn’t add the source language to the list of target languages, because the source strings were all procured from the same repositories that the translations were getting sent through to. This was utilising the “Source and translation files mode” of VCS integration (GitHub), so branch configuration was pulling a resource file, with a full set of source strings in the source language (English). Then when the time came to sycnhronise translations back to the repositories, the target languages did not need to include English, since those source strings were already present in each repository. :sweat_smile: (I hope that makes as much sense to you as it did in my head! :rofl:)

Now in the case of this new project’s localization workflow, the source strings are generated within Figma, from the copy present in design frames in that project. :building_construction: The idea here is that the designers can build UIs that contain strings, that can then be sent through to CrowdIn with unified key/identifier naming, and once translated, those strings can then be pushed through to the app repositories (Android and iOS) in the formats they require. :metal: The keys used in both codebases would remain uniformed, making things more manageable for the Engineering Teams :technologist: working on these projects. :handshake: Since the strings are sourced from Figma (in our case), the source strings are not present in the destination project repositories, so the source strings must be pushed through alongside the target language strings. :dart:

This method of sourcing strings and generating required target bundles (inclusive of the source strings) is briefly mentioned in the following blog post:

This method seems to be required for use-cases where the source strings are procured from somewhere other than the place that the translated files are destined. I’d imagine most “Strings Vault” (.csv) workflows would require the source language to be included in the target languages list, particularly when the “Strings Vault” is created using a plugin (like the Figma plugin) or from within the CrowdIn “Source” UI, pictured below:

I hope all that makes sense! :sweat_smile: As always, I’m totally open to suggestions on ways to improve this workflow, though for the moment, I hope these walls of text can help guide those trying to achieve something similar! :rocket:

Hi @forcite,

Hmm, for some reason it seems to me that you do not need to have English as the target language in the project if you have English as the source language

Let’s do it this way, I will increase the project limit for your account by one by the end of the month (until the end of July), so that you can create an additional project that mirrors the one you already have, and you can test everything nicely on it without fear of harming the main project. That is, a sandbox project for testing

Does that sound good to you? I have already increased the limit

Hey @Roman, thanks for jumping in and for the opportunity to test an alternate approach. I really appreciate it! :pray:

May I ask how I’d go about getting up-to-date English strings into my mobile app repositories, if I don’t specify it as a target language? As mentioned (in my second post in this thread), the source strings for my CrowdIn project are originating from Figma (via the Figma plugin).

For example: if I were to go and add a new English string to one of our Figma designs, the mobile app repositories would not have this string in their respective resource files nor knowledge of any changes made to the Figma designs. This new string instead gets pushed up to our CrowdIn project, where it’s passed through to the repositories alongside any translations that are made. If I were to omit the English language from the target languages list, I end up with only the translations to the new string, but not the new source string itself (in English).


Well, an interesting question. Would you be able to make synchronization of the source column in .csv for English? :thinking:

From the 1st post, I can see that your question was about removing the folder with EN translation (values en), and if the project will not have English as a target, this folder will be removed from integration. The system just can’t “skip” translation for 1 language. Well, it can, if you use API or another tool and download only 5/6 languages, and keep 1/6 always skipped.

The best way to be sure about it would be to follow Roman’s suggestion and do the test in a new project. Figma can be copied, repositories can be forked and used for the test as well. :face_with_monocle:

I’ve gone ahead and activated a Free Trial for your account - it has unlimited branches, integrations, limits, and all the things you might need for the test. Feel free to play around with different setups.

A free trial will automatically expire in 2 weeks and once it does you’re welcome to jump back to the Free plan. Or mention me here and I’ll switch your account from my side :wink:

Hey @Dima thanks again for your reply.

Would you be able to make synchronization of the source column in .csv for English? :thinking: @Dima

Actually, the source strings, provided by Figma to CrowdIn do exactly this. The .csv strings vault that all the source strings are getting added to (incrementally, as the Figma designs evolve) are in English.

In my first post, I was not trying to remove the entire English as an output, but rather just the -en suffix that was getting appended to the end of the values subdirectory name. (There doesn’t appear to be a straight-forward way to treat one target language’s “resulting file pattern” differently from the rest using the online Branch Configuration tool/feature.)

That said, at the end of my first post, I presented the only workaround that I could find to achieve the required output for the English (default) target language. :dart:

Perhaps there’s a way to “pass through” the source strings as an output, when generating target bundles? This would mean that my source strings (from Figma) would become the English target language that I require outputted (to my GitHub repositories), along with the translated target language strings. This is the only other way I can see to get new/updated English source strings from the Figma project, through to the GitHub repositories (without unnecessary manual intervention, of course).

This is what my localization workflow looks like (I hope that maybe it dispels some confusion here):

Step Platform Action
1 Figma Upload source strings that were added to Figma project to CrowdIn using Figma plugin.
2 CrowdIn Translate source strings uploaded from Figma project.
3 CrowdIn Proofread translations. Iterate for approval.
4 CrowdIn GitHub integration is triggered, causing the configurated target bundles to be generated (using the Branch Configuration for the two attached repositories).
5 GitHub Translations and new English strings are made available in a new localization branch in each repository for review and inclusion.

Given this workflow, the sole reason for including our source strings as a target language is because there’s no way to get the new source strings from Figma into the GitHub repositories without manually adding them. In my second post in this thread, there’s a CrowdIn blog article that I linked which briefly mentions the exact method I’ve leveraged in my workflow, to achieve the desired result.

Here’s the excerpt:

I hope that clears things up! :muscle:

Hello @forcite

Thank you for the highly detailed explanation, I really appreciate it. Now things are totally clear to me. Yes, you were right at the beginning that the workflow you’ve developed is the best so far.

We have an upcoming improvement (for API) that will allow you to use a specified source language or select one of the target languages as a source (for that particular call). This functionality wouldn’t be added to the native Github connector, but as it’s based on API, users can switch at any moment.

Still, as for now, I’d prefer your workflow. There are some advantages in native connectors, plus, if everything works fine and you’re happy with the result, seems like there’s no need to change anything.

1 Like