Consecutive commits translating back & forth from Portuguese (Brazilian) to English

Lately, I noticed a couple of commits on my translation branch (l10n_master):

  • New translations strings.xml (Portuguese, Brazilian)
  • New translations strings.xml (Portuguese)
  • New translations strings.xml (Portuguese, Brazilian)
  • New translations strings.xml (Portuguese)

In these commits the strings in app/src/main/res/values-pt/strings.xml are changed first to Portuguese, then to English, then to Portuguese and finally to English again.
What is happening here and why? Is there something misconfigured on my project?

  • GitHub: EventFahrplan/EventFahrplan (sorry I am not allowed to post links for some reason)

Maybe it’s related to duplicates or to dialects options. Also, key may have changed (not the source string, but the ID of this string), so system consider it’s as new, and erase current translation, then pre-translates the project (if there’s a workflow) or share translation from duplicate, or grab from GitHub, can’t say for sure.

Need to be you and to sit at your place to say exactly what’s happening :slightly_smiling_face:

By the way, what the reason for such interesting path? Maybe it’s because there are some contra versions between source and translation, I assume your source is stored in values-en?

Probably try using more simple path, something like in Crowdin docs


So there wouldn’t be any “touch” with values, and all translation would go to stand alone folders

But this is just an assumption, my GitHub is very basic, never tried something interesting in terms of configuration :slight_smile:
Maybe you’ll find something that might help in Crowdin’s Git repos, or in documentation.

The path is the standard path used in Android application projects based on Gradle. I believe Crowdin has built-in support for this project structure.

Crowdin has some unique features. For example, spaces in branch names are allowed, and so on. Probably this one (Gradle support) is also a part of these features :slight_smile:

@Dima Can you explain the commits to me?

Hello, @tbsprs I assume that the reason is in dialects and\or export settings.

I need to see the full project configuration, requests, and probably a screencast with the issue being reproduced. It would be better if you raise an issue on GitHub so all links and all details would be visible to me and the development team. Or message me here in direct conversation.

@tbsprs just done a few tests from my side, most likely your behavior because both languages are pushed into 1 language.

Try changing the configuration to include locale patterns:

As a result, you should have 2 folders, one for pt-PT and another for pt-BR. You can also map languages, so as result there would be for example PT and BR (if you’re strict to 2 letters code).

@Dima thank you for the investigation. I am happy to provide additional information to you.

… because both languages are pushed into 1 language.

What do you mean by this?

I have not configured any language codes in the crowdin.yml file:

  - source: /app/src/main/res/values/preferences.xml
    translation: app/src/main/res/values-%two_letters_code%/%original_file_name%
  - source: /app/src/main/res/values/strings.xml
    translation: app/src/main/res/values-%two_letters_code%/%original_file_name%

And the languages configuration looks like this:

@tbsprs you’ve added %two_letters_code% in the translation pattern. That’s why the system can’t recognize the languages properly because in 2 letters they’re both just “pt”

You need to add locale, so the system would “see” pt-PT and pt-BR, or map pt-BR to another code.

1 Like

@Dima Thank you. That wasn’t obvious to me. I changed it now.

  - source: /app/src/main/res/values/preferences.xml
    translation: app/src/main/res/values-%two_letters_code%-%locale%/%original_file_name%
  - source: /app/src/main/res/values/strings.xml
    translation: app/src/main/res/values-%two_letters_code%/%original_file_name%

Let’s see what happens now. Do you expect that Crowdin will push new commits to my integration branch?

@tbsprs the 2nd one would remain unchanged.

You need to have something like /res/values-%locale%/%original_file_name% in order folders with languages not being overwritten.

For the 1st one, I’d rather go ahead with simple %locale%, can’t say for sure that the system would work properly with both 2 letters and locale in a folder name %two_letters_code%-%locale%.

For the best experience, I’d advise having only 1 language code pattern per folder step (e.g. per /…/ ) and adding a subfolder for 1st or 2nd translation path, to prevent level-based conflicts (e.g. they shouldn’t be totally the same).

You were granted an additional project for test purposes in past, it’s still (and it will be eternally) up and running, so you can do all necessary tests to check whether the path works properly. Probably better to configure via integration UI because it provides visibility.