Setting the translation parameter should not change the project configuration

[richardsd]

Hey team, I don't really know if this exactly an issue, but it doesn't feel right to me. I have a crowdin project with the folowing structure, with different source files on different directories:

root
- folder1
-- messages.json
- folder2
-- messages.json
- messages.json

The top level messages.json has the following export configuration:

On GH I have a workflow that uses the crowdin/[email protected] and I set the translation parameter with: /i18n/messages-%two_letters_code%.json. I'm doing this mapping because in my local project, the translations are located in a different directory.

The problem is that when I pass the parameter with this value, the project configuration is updated and if I go the Crowdin project to download it, it is using the last configuration provided by the github action, and not the one I manually add to the project.

I don't think that overriding the configuration should be the expected behavior, but is this a bug, or an intended feature? Thank you team, waiting for your feedback.

[dianaIosm]

Hello @richardsd!

This is the expected behavior since the file would be exported according to the configuration option you've saved. Otherwise, the Github Action for this file would not be functional.

The same file can't have two different export options within one project.

Hope this answers your question!

[richardsd]

Thank you so much @dianaIosm for the quick response.

In my understanding, I really thought that the GH action was not updating the export config of the source file at the Crowdin project definition, but rather that the properties were just the action configuration. It felt strange that the action would change the project config "destructively", but now I understand the behavior a bit better.

Either way, thanks for the clarification 👋

[Gabez0r]

I was also expecting the action to be self contained. For example, there might be two client projects, using the same Crowdin project, leveraging the github action to download the translations. However, both can use a different translation pattern, for example, one using %two_letters_code% and the other %locale%. In this case, any user building and downloading the translations from the Crowdin web site directly will get a different folder structure, depending on which project run last, which leads to some inconsistency. Is this expected? How can we work around this?

[andrii-bodnar]

Hi @Gabez0r,

The Crowdin GH Action is based on the Crowdin CLI. CLI is closely connected to the translation pattern.

The possible solution is to use branches in Crowdin - files within each branch will have their own structure and translation pattern. The duplicated strings could be managed using the duplicates strategies.

[Gabez0r]

Thank you for the response, @andrii-bodnar. So, if we want to have the very same translations and just use two different translation formats, i.e, export the files with a different pattern, but without having the config constantly switching between exports, we should have two branches duplicating the same content?

[andrii-bodnar]

@Gabez0r could you please provide a more detailed example of your setup? Maybe there is another solution but I need to better understand your use case

[Gabez0r]

My last comment concerned a future use case. Our current use case is a bit more simple but still affected by this issue. We have the following consumers of our Crowdin project:

1. Two github workflows which now use the github action to sync the labels.
2. A legacy Jenkins job that downloads the translations using the already deprecated https://api.crowdin.com/api/project/{project-identifier}/download/{package}.zip endpoint
3. Users that build and download translations for validation directly in the web site.

The fact that 1) destructively changes the project settings affects 2) and 3), although I understand that 2) relies on a deprecated endpoint. 3) is a bit more disruptive, as the format suddenly changed.

[andrii-bodnar]

Hi @richardsd, @Gabez0r,

There is a new alternative GH Actions solution that is not based on the Crowdin CLI and can be used without affecting the "Translations export pattern" - Crowdin Request Action

Maybe, it could help with your use cases as it gives more flexibility since you have more control and freedom on the Crowdin API usage

[richardsd]

Hey @andrii-bodnar,

Thanks for getting back to us on this subject. We are not actively working on the topic anymore, as we based our solution on current behavior for now (and we are now in a new team), but I'll make sure that this information is passed on to the new team. Thank you very much.