GitHub Integration throw error: Error while uploading translation: b'Cannot update the source language'

[bigretromike]

This happens to all my project right now, after adding new project first PR is made successful and then it stop working.

On of those project is located here: GitHub - bigretromike/nakamori.script: Nakamori module
My YAML file is:

filters:
- filter_type: file
  source_file: resources/language/resource.language.en_GB/strings.po
  file_format: PO
  source_language: en_GB
  translation_files_expression: 'resources/language/resource.language.<lang>/strings.po'

While this worked for first time, the GH integration stop to work after first PR (I have setup that 100% reviewed translation is being send as PR)

I already wrote to support, but its been some time and no response so Im hoping someone here will help to figure out why transifex stopped to work for me.

I initial thought that it was because the output folder was missing (the language I added was new and pushed empty directory to repo , but that was not the issue).
Transifex in fact does create branch for the language that he try to push but it failes with ‘Cannot update the source Language’ and stop working

[nina]

Hi @bigretromike,

Thank you for posting to our community

I already answered your question to the ticket you submitted to our support, but since your question was also submitted here, I am including my response here as well in case someone else comes across the same issue.

So:

Regarding your case, after checking this out, I confirmed that both source and translation files have successfully been synced. Specifically, if you check your resource in Transifex, you can see that the source file was created as expected and the Polish (Poland) (pl_PL) translations were also synced. I assume that these are the only translations that are currently stored in your Github repository. Can you please confirm?

The issue seems to be the way your source and translation files are stored in your Github repository. To be more precise, it seems that your file structure looks like this:

where resource.language.en is the folder where your source file can be found.

So, the system tries to sync both source file and all the existing translations but then while trying to find all the files under ../resources/language/resource.language.<lang>/strings.po, the folder “…resource.language.en_GB” is considered subfolder for your translations too and the system tries to map it to a target language in Transifex. However, since the “en_GB” locale is actually the source language of your project, it eventually fails.

This means that in the logs you received:

the file that fails to be synced refers to the source file that the system mistakenly considers as a translation file.

We need to find a way to exclude the source file while checking the file_filter path when both source and translation files are hosted under the same directory and their subfolders’ name matches.

So, there are 2 suggestions for you in order to move forward:

1. Ignore the error in the logs since this does not really affect the integration or

2. Create an intermediate folder for your translations to differentiate like:

   /.../language/translations/resource.language.<lang>/strings.po

   instead of

   /../language/resource.language.<lang>/strings.po

so that the system will easily distinguish the source from the translation files.

Let me know if the above helps.

[bigretromike]

Yes, I also answer you there.

But I will include short version here if someone need help.

1. No I cannot make folder structure different because the project is a part of a addon that is used for 3rd party software (Kodi) that have the structure made this way, I assume that the workaround would be to move out the source file to somewhere else and then also copy it to output folder - that I could do if there is no other way.
2. I sadly cannot ignore the error I mention because in fact the process failed to sync other languages (you can check other project in same organization: nakamori-lib, that have one extra language 100% reviewed but sadly transifex fail to send it).
3. Also is super strange (the folder structure because I dont use short lang codes ‘en’, ‘es’, ‘fr’ I use those ISO based ones, ‘en_GB’, ‘es_ES’, ‘fr_FR’

[nina]

Hi @bigretromike,

Thank you for following up and for sharing additional information.

1. Changing the path for source file instead will also work since this will help to differentiate source from translation files. Would it be possible to try this out and let me know if this fixes all the issues?
2. I checked this but the logs do not appear We will further look into this and let you know. Thank you for reporting this.
3. I am sorry for the confusion. In my example, I used generic locales, but it is definitely fine if you want to use language codes like the ones you mentioned. Both work

[bigretromike]

As you can see in nakamori-lib project, I edited YAML:

filters:
- filter_type: file
  source_file: resources/language/before-translation.po
  file_format: PO
  source_language: en_GB
  translation_files_expression: 'resources/language/resource.language.<lang>/strings.po'

This sadly results in “/resources/language/resource.language.en_GB/strings.po Error while uploading translation: b’Cannot update the source language’”

Any others ideas what can I do to make it work?

[bigretromike]

I removed old resource file also, added only the new one. And the issue is still present.

[nina]

@bigretromike

Could you please remove the source language folder from this path since this confuses the system?

Specifically, the folder " resource.language.en_GB" should not be under the nakamori.lib/resources/language directory.

Once you do that, could you try once again? This should fix this issue.

Please note that as long as the source folder exists under the file_filter path, the system will keep trying to map the source with one of the target languages of your project.

Please let me know how it goes.

[bigretromike]

Ok, for now I deleted folder you asked. After ‘fake’ editing YAML it does finish without issue, I don’t see the PR from Transifex but I assume its a delay thing (I’m not sure if it should be instant or just after some time). Strange that he see only 1 Translation instead of 2. ( Uploaded Translations: 1/1 )

If this work, I still cannot use it because the en_GB language is default for the platform I’m coding, and having that file outside of language structure is bad.

Is there any ETA for somekind fix ?

The only workaround that I see is to delete all Project, Create them with “English” as default language and then make a ‘fake’ en_GB that would be 1:1 with source file or maybe map it somehow so I will get en_GB inside translation folder. But then again I need to download each translation from every project that I have and then upload them to GH manually or on transifex because most of them ain’t up-to-date with GH

[bigretromike]

Still the PR didn’t go, but the question is - do I need to make empty file on my GH for new language that I added and translated on transifex to make the new language being bushed to GitHub repo or does it itself create new language files on repo?

[nina]

@bigretromike thank you very much for trying this out and letting me know.

Please find my comments below:

1. The system sees only one translation file because in your Github repo, there is only the “resource.language.pl_PL” folder. Please note that 2 files were actually synced: 1 source file and 1 translation file

2. in order to re-trigger the integration and check if the PR is created without issues, I would suggest you delete a Chinese translation and re-translate it. This should immediately fire the webhook and create a PR in your Github repository

3. ETA. Unfortunately, we need to evaluate the way this works and see how this can be addressed on our end. I cannot provide you with an ETA but I will keep you posted on any further developments

4. Workaround: What you described might work. Specifically, you can add “en” as source language and en_GB as a target language. In your Github repository, you need to ensure that these files are always identical, so that whatever changes in your source will be transferred to your TX project

5. Empty file: No need to manually create new translation folders in your Github account. As soon as a target language is fully translated in your TX project, then integration will be triggered and a PR will open in your repo

[bigretromike]

Ok, thats a lot usefull information because I was hoping I could re-trigger event by un/review same string.

I end up removing all projects (my god help anyone with bigger structure than mine), set all of them as EN (English), yet craft this YAML:

filters:

• filter_type: file
  source_file: resources/language/resource.language.en_GB/strings.po
  file_format: PO
  source_language: en_GB
  translation_files_expression: ‘resources/language/resource.language./strings.po’

As you see even when I setup Project as ENGLISH (en) I point en_GB as source inside SAME directory as result. And while exporting and importing and reviewing same strings I did trigger push for both Polish and Chinese translations, so for now this way somehow works, but I think there is some issue in that GitHub Integration like the one you point out before.

We will see in a long run if this setup works fine, because making duplicate files for en_GB and en would be a hassle.

Also thank you for trying to help out, I hope I wont encounter any “remove project, readd it to fix” kinds of bugs anymore

[nina]

@bigretromike I am glad to know that it eventually worked for you and I am really sorry to hear that you had to do these changes on your end in order to make this work as expected.

Please let us know if you come across any other issues and we will be more than happy to assist you.