I have a problem using the Github Action / Crowdin CLI. I have the "update_option": "update_as_unapproved" added to the files array of my crowdin.yml, but it still just adds translations to crowdin.
I added these snippets to the product 2 days ago and now I see the API has added it to crowdin but just as an additional translation, ignoring them even when I click on “proofread”. But the options should just unapprove such edited snippets, right? What am I doing wrong?
Could you please share the project identifier (you can copy it from the project url) or the project name in which you update the files? And also please tell me the name of the file in which the string was updated, for example, the name of the file in which the string from your first screenshot is located? Then we can check the log from our side
The “update_option”: “update_as_unapproved” option is used when updating the source file, if the source string with the translation is updated, then this update will leave the translation but make it unapproved
The ID is 361671 and the project is shopware6.
All files and all snippets are affected, but one specific example is in de in the file SwagB2bplatform/Storefront/storefront.json with the snippet key b2b.CityAsc. It’s not from the screenshot anymore, since I have to continue working and fixing the by hand, but that specific one I left now.
That’s the least I would have expected from that flag. I personally would love that the new translation would be accepted, so I do not have to accept them myself…
Do I understand correctly, that the update_option should see “This snippet is translated ‘foo’, which is approved and now I update via CLI that the snippet is now translated to ‘bar’.” As far as I understand the flag, now “foo” and “bar” are both NOT approved anymore. But in our files, it keeps “foo” as approved, which doesn’t do anything for us Same as no flag.
As my colleague mentioned before once you are using the option “update_as_unapproved” the previously added translation to the string will preserve. But if the string was approved the approval will disappear. Here is more info regarding the update options:
Could you please let us know which CLI command did you use?
I understand the flag isn’t unapproving items as expected when using GitHub Action. We will consult with our devs on the matter and will come back with updates!
Update_as_unapproved is using for updating sources, not for filling in the translation. If the source string changes in the source JSON, the translation to it remains, and the approval, if it was there, wanish.
If you want to automatically approve added translations you should add this option auto_approve_imported: true
To sum it up another time:
If English is my source, and I upload English it as such using import_eq_suggestions: true, it should upload english as source and translation.
If it was an override, an approval will be removed. Yes?
We are also uploading german, since we’re a german company. But currently I have the weird behavior, that it just uploads german, but just doesn’t apply such strings to crowdin. I have the feeling it pre-translates english and approves that, ignoring there was an approved translation, which hasn’t changed.
Totally, it’s complete mess with crowdin. It started to behave that way starting API v2. With this in mind, it’s currently impossible to let users of crowdin translate english or german, which is quite annoying.
If you are using import_eq_suggestions: true it means that once you are uploading the translation that is the same as source string then the system will pick it up. For example your source string is “Hello” and the translation should be also “Hello” then you should use that parameter.
Uhm… I don’t wanna be rude, but did you read the post? I know that, I told you that that flag works as intended but the other options are problematic.
Everything below me just mentioning using the flag is the issue here…
I added English and german, and as long as I don’t manually approve the new strings AND DELETE THE OLD ONE, it just approves something I did not even upload, which is probably pre-translated
Hi @marcelbrode
From what I understand the import_eq_suggestions: true is working fine and you don’t have questions anymore
As for auto_approve_imported: true it should overwrite your existing translations and automatically approve those that you uploaded. It is not connected to your source content, auto_approve_imported: true parameter only checks translations
From your message it is not quite clear if German translations were successfully uploaded as approved and overwrite the existing translations or not: it just uploads german, but just doesn’t apply such strings to crowdin
Please read the full post. After your quote of my text, the parapraph isn’t finished and provides crucial information.
I added English and german, and as long as I don’t manually approve the new strings AND DELETE THE OLD ONE, it just approves something I did not even upload, which is probably pre-translated
So you say approving something entirely different automatically is intended behavior? Uploading a snippet key “myKey” with the translation “B” leading to approve the already existing translation “A” and ignoring the newly added “B” is correct?
Sorry for the inconvenience and misunderstanding! This indeed does not look like expected behavior. Perhaps you could share with us some examples of strings and your current configuration (if it has changed from your first post) so that we could check everything from our side?
Also, let me please sum up this case. As far as I understand from the whole conversation, you are uploading new translations to the project. The “update_option” parameter works only with the source files, meaning if you need to make some changes to your string (e.g. change “Hello” to “Hello there”) and you think that you will need to modify the translation for this string as well, then you can use the “update_as_unapproved” so that to remove approval for the existing translations.
This means that the “update_option” parameter will work only towards the sources (“crowdin uploaded sources” command in CLI). If you’re uploading translations, it will be useless.
On the other hand, “auto_approve_imported: true” parameter will work with translation and will approve the translation that has been just imported.
I understand that this does not work as intended, so please share with us some examples of what you’re uploading and what you receive. We will be happy to investigate your case more closely!
Thanks for the effort. Yes, this sums up how it should be the case. Either way, the upload does not be applied, neither using auto_approve_imported: true, nor update_as_unapproved. To use your example: I upload “Hello there”, as an update, but it still falls back to “Hello”, which was approved before.
I currently have fixed all the snippets manually, so I’ll update this topic when there’s new example, since they definitely will appear again, but this will probably take some days.
Ideal example on how our software changed translations, and Crowdin just ignores "update_option": "update_as_unapproved", It just keeps the old translations, so I have to change manually everytime anything changes. This is annoying as hell.
If I follow @TaniaM s Explaination, this should exactly be the case, when update_as_unapproved should work, since someone changed something in the product, the automatisms push that to crowdin but crowdin just doesn’t really care.
Dunno if this helps, but this is in german of projectID 361671.
As we can see, the string doesn’t have the activity record about source text update:
It only has the record about translation upload but you tried to upload the same translation that was already added in the Editor. In this case, it’s needed to delete the previous translation and then upload a new one
If you mentioned a different string, please feel free to send us the link to the exact string:
Same as no flag.
