Oof… I must admit, it’s extremely difficult for me to answer here anymore without being enraged. I try my best to stay professional.
I am not exactly sure if you got this, but as you can see in the screenshot above, the translations aren’t the same. It’s only an empty space character, but there’s difference.
And I also told you it’s a general problem. I’m not here for a single snippet. We are not a small company, we have like 50.000 snippets. That happens all the time. I just tried this in the browser to change the value of a source string with the option “remove approval”. This works there, but it doesn’t work with the API.
Let me repeat my problem:
Steps to reproduce
Let’s say I have a snippet with the value “Select kamera” in our software.
I change the value in our json files to “Select camera” and merge it to my repository
The GitHub action and stuff uses my crowdin.yml file, which contains "update_option": "update_as_unnaproved" to push everything to crowdin
Expected result
In crowdin, I see my source strings value “Select camera” and in my english translation it also says “Select camera”, as well as the old snippet “Select kamera”. Both unapproved.
Actual result
The same as expected but the old, wrong one is still approved, so that the automatic download ignores the new one.
Hi @marcelbrode ! I have checked the case and the project in question once again and am back here with what I noticed
First of all, since you were uploading a new translation, the option “update_option”: “update_as_unapproved” is not relevant here since it works only for the source text update and in your latest case you added translation, not the source so let’s put this option aside.
What you need in your case is auto_approve_imported: true option and after checking the project logs (I checked the exact date and time when you uploaded that translation mentioned before which is June 04, 16:09) there are logs about translations upload but the option specified there is autoApproveImported: false
You may also check the same in the API logs of the project, so that is why the changed translation was saved as a suggestion only (since there’s already an approve)
Here’s how it looks in my file and translations were approved
If this flag is designed to unapprove source strings but source strings themselves cannot be approved or unapproved, does this mean that the feature is essentially useless?
This situation forces me to manually check every automatically uploaded snippet, which contradicts the purpose of having an automated process (something I’ve been doing for months now…). Alternatively, I would lose the ability to proofread everything because I would have to auto-approve instead of “update as unapproved”.
Could you please clarify if I am misunderstanding something, or if there is a workaround to this issue?
Hi @marcelbrode Let’s take a look at the two options discussed
update as unapproved- this one is applied only when the source file is changed. So for example I have a source file with English Strings inside that I will later translator to other target languages (Spanish and Norwegian)/ In that file I have a string Hello World!
My translator saw that I uploaded it to the project and went ahead and translated it into Norwegian and Spanish → proofreader approved translation because all is correct
So now I have:
English (source string) Hello World!
Norwegian “Hallo Verden!”
Spanish “¡Hola Mundo!”
After this, I realized that the source string should be Hello world not Hello World! and decided to edit (update) the source file. So I changed the string to Hello world
What will happen after this change: the system sees that the source string is different now and assumes that translation should be also different so by default my translations (Spanish and Norwegian) will be removed (so that translators could see that string is not translated and add correct translation)
But with the help of the option “update as unapproved” you may keep the translation, even though the source string is changed now. So this option will keep my translations “Hallo Verden!” and “¡Hola Mundo!” but they will be unapproved now (so only my proofreader will see that something changed and correct the translation based on the change)
autoApproveImported - is applied to uploaded translations only
Let’s take a look at the same case: I have a source string and I have translations that are approved. I realize that translation is not correct (translator didn’t take into consideration the context and another word should be used for example)
I have the file with correct translation on my computer and want to upload them to Crowdin. By default the translation from the file I upload will be uploaded as suggestion only since the translation in Crowdin is approved and has higher priority. So to make this newly uploaded translation approved (and become main one) you may use the option autoApproveImported:true
Now I’m a bit confused. In short, update_as_unapproved detects changes in the source string and therefore unapproves every translation of this source string, right? But that’s exactly what I want and it’s not working. As I mentioned before, this is an automated process of a larger software. Of course, there can be new strings, but it’s also common to update strings, which means updating sources. Therefore, I want the translations of that string to be marked as unapproved. So, in fact, it should do what I want?
Another question: autoApproveImported will probably auto-approve everything I upload, right? Since German and English are uploaded only for reference in our software, do I need to split the crowdin.yaml into two files for:
Uploading only English and German with autoApproveImported
Downloading all the languages with remapping of the locales?
Because otherwise, autoApproveImported would override changes on Crowdin when all translations are uploaded as well?
as for update_as_unapproved, yes, it should update the source text but leave the translation unapproved (so basically delete approve only but leave the current translation.
Could you please do some test updates of the source so we can check the fresh logs?
autoApproveImported will probably auto-approve everything I upload, right? - correct
so if you locally have some changes in the translations, they will be uploaded to the project and at the same time approved (will become the main ones)
You want to only approve one language during the translations upload?
when you download the translations from the project, the option autoApproveImported won’t be applied here. It works only on import (when uploading translations to Crowdin)
The configuration file is taken into account both for uploading and downloading. If you want to download only a specific language, you can specify this directly in the CLI command or API request.
That means I am right with my assumption that I need 2 files, since download and upload are not the same files.
BTW: Regarding the not working option. My colleague changed something and I can give you “fresh logs”.
Have a look at sw-media.image-generator.image_root_folder_name. The content was Root and should be changed to Root folder. I tested it on friday, to approve the old one and remove the new one, since I knew our schedulded uploads will change it again. And there you can see it. It adds Root folder as a second translation, but the original one is still approved.
Please tell me me when I can change it and you have seen the logs you wanted to see.
That means I am right with my assumption that I need 2 files, since download and upload are not the same files.
Do you mean 2 source files? The source file should be only one (meaning one sample of it), and also separate files for translations. Alternatively, you can have a single file both for source and translation (if you have a source language as the target, for example), but then there is a risk of overwriting some strings. In such a case, it is recommended to keep such files separately.
Regarding the not working option, I can see from the activity in our database, that the request to upload translations was used. In such a case, it is expected that the option update_as_unapproved is not taken into account by the system. When uploading translations, the system simply uploads the new translation as another suggestion.
The option is applied when you change the value of the source string only (e.g. source string “Root” to “Root folder”) → then trigger the request to update source file → and then the existing translation for the string will be unapproved if the update_as_unapprove: yes is present in the config because since the source is changed there is a reason to believe that the translation need to be changed as well. While the request to upload translations simply adds a new translation to the existing string.
Regarding unapproved: But that’s exactly what I’m doing. I uploading source files, I use the flag to also upload the sources files as en-GB translations, therefore it should work, shouldn’t it?
The option update_as_unapprove: yes would work if you are updating a file in Crowdin. Then for a string where the source text was modified, the translations will be updated and marked as unapproved,
