Xcstrings again

Hello,

We are facing a few more issues with xcstrings lately:

  1. We have nb_NO as language in Transifex. When pulling the xcstrings file we see nb_NO and nb-NO. Where is this duplication coming from?
  2. When pushing this file then back to transifex we get errors: “owncloud-ios.sdk - failed to upload of resource ‘o:owncloud-org:p:owncloud-ios:r:sdk’ - parse_error: Multiple different entries for language code: nb_no or NB_NO”
  3. lang_map does not seem to work - we only want to see nb-NO which is the language code how xcode understands them

Thanks a lot,

Thomas Müller

Hi @thomas.mueller

My name is Carlos from Transifex support, can you share please how are you handling the lang_map in your config file?

I’m attendant to your comments,
Kind regards

Hi,

I tried mutliple different lang_map settings - they are simply not applied from what I can tell.
One try: lang_map = nb_NO: nb-NO, nn_NO: nn-NO, pt_PT: pt-PT, pt_BR: pt-BR

Thanks a lot,

Thomas

Dear Thomas,

I hope you are well.
We have tried to reproduce the issue you have mentioned but could not.

Is it possible that you share with us at support@transifex.com the original source file , that you first uploaded to Transifex? Have you done any mapping via xcode, besides your tries with lang_map via our Go Cli?

Is the xcstrings file at any point used to export anything new from inside xcode after it has been downloaded from Transifex?

Looking forward to your response. Feel free to share all details directly to support@transifex.com

Kind regards

Hey Chris,

thanks for your support!
All files are in the linked GitHub repository - what else can I provide?

As per git history this is the version which was uploaded to Transifex first: ios-sdk/ownCloudSDK/Resources/Localizable.xcstrings at 52994ee2cdbd6bd7d5611f78c25949d01f9d04e4 · owncloud/ios-sdk · GitHub

Let me know if you need any more information.

THX a lot

And with the first tx pull nb-NO and nb_NO appeared - from this day on the file was basically broken and could no longer be pushed back to transifex.

Dear Thomas,

Apologies that this took a while.
We managed to reproduce the issue. It is not the client itself that caused the addition of the Transifex locales. In our tests, the client on local directories and outside Github repos did not cause the same behavior.

This is still under investigation. It is a combination of the file format and locale mappings used while syncing to Github.

In regards to the failure to upload back to Transifex. This is expected. You will need to manually remove one of the locales nn_NO or nn-NO so that it will be uploaded. I recommend removing the nn_NO locale from the file, as I presume you need the nn-NO mapping for using this in your project. Same for the rest mapped locales.

Then, you can upload it to Transifex. Do not use locale mapping. Transifex will map by itself the nn_NO locale with the files nn-NO. Rest of the locale mappings will follow same logic. If everything goes well all similar locales will map automatically.

Give it a try, and let us know if you see any issues again.

1 Like

Hi Chris,

thanks a lot for your feedback!

To clarify - we are purly using the tx cli tool to push and pull. The github action we are using in our workflows are calling tx. So we are not using the transifex github integration (which btw does not support xcstrings…)

We for sure can change the file content and remove nn_NO - but on the next pull we get it back. So we need to implement some jq-fu. Let’s see.

But may I ask why nn_NO and nn-NO is of any issue when we push the source which is en? Kind of weird …

Thanks a lot & enjoy the upcoming weekend,

Thomas

Dear Thomas,

No misconception here. I understand that you are not using the github integration and only the cli to push and pull.

I also made tests alone with cli. Since the issue is not reproducable when the cli is used outside Github, I then checked what happens with github repo in the “picture”. So the error is observed once github repo is in the loop.

For the project to work again normally please make sure to have a clean file (meaning an xcstrings file with only nn-NO, pt-BR inside like the original you had uploaded).

But may I ask why nn_NO and nn-NO is of any issue when we push the source which is en? Kind of weird …

XCstrings is a kind of unique file format because you have everything in one file. Source strings and translations. That is why you get the error, because translations are inside no matter what. And the erroneous file right now includes both nn_NO and nn-NO.

So, at this point you will need to clean up the last version of the file you have and please , make sure to make a new upload to the project on Transifex. Because, right now both files on Transifex and on Github side, have these additional locales. They have been corrupted.

I would recommend to erase the resource from Transifex and make a new upload. After that you can again try to push pull without and language mappings and let us know if you again face anything like that.

Kind regards

1 Like

Hi Chris,

we just successfully pushed the source language [fix/transifex-duplicate-keys] Remove duplicate locale keys before pu… · owncloud/ios-sdk@1f12f5c · GitHub

Thanks,

Thomas

Hi @thomas.mueller

My name is Carlos from Transifex Support; I’ll step in while Christos is OOO. I’m glad to read that you can successfully push the source language.

In case you need any further assitance please feel free to write us again,

Best regards,
Carlos

1 Like

Consistent Language Codes: Make sure that the language codes you use for your project are the same. Update all references to utilize the same code and stick to a single format, either nb_NO or nb-NO.

Update the configuration for lang_map: Make sure your lang_map setting is formatted appropriately by checking it again. For instance:

Lang_map = nb_NO: nb-NO, nn_NO: nn-NO in plaintext
Speak with Transifex Support: It would be preferable to contact Transifex support for help if the problem continues. They can help fix the duplication problem and offer more detailed instructions.