Options for more control when uploading translations

[finebel]

Hey,

I'm looking for more granular options to restrict which translations are uploaded to Crowdin. For crowdin upload translations you can use the --language argument which is great but for our use case (see below) not really sufficient.

Example

The source strings are in a file called de.lproj/Feature1.strings. The translations are stored in <langauge code>.lproj/Feature1.strings.
Now, there are a couple of scenarios:

1. We only want/need to upload translations for a specific key.
2. We only want/need to upload all translations present in one translation file (e.g. en.lproj/Feature1.strings).
3. We only want/need to upload all translations for a specific source string file (e.g. upload all translations for the source strings in de.lproj/Feature1.strings).

Question

Are there any plans to enhance the CLI to cover (at least some of) the scenarios outlined above (especially scenario 1)?

For us, this would be a huge timesaver as running crowdin upload translations for all translations takes 7-10 minutes in our project.
Note: The crowdin file upload <path> command seems to be designed to only upload source string files.

Background

Unfortunately, in Crowdin there seems to be no option to automatically ensure that the first letter case of a pre-translated string matches the first letter case of the source string (e.g. if you have a German source string that is Haus, the English pre-translation might be house).

To adjust this, we have a local script (in the example above, the script would change house to House).
However, this means that whenever we run the script, we need to upload the updated translations.
Note: In such a case, oftentimes most of the pre-translated strings use the wrong first letter case, making the --language option for crowdin upload translations not really helpful here.

[andrii-bodnar]

Hi @finebel!

You can use the crowdin file upload command for more granular options. By default, this command uploads source files. However, when the -l parameter is specified, it works as a translation upload for the specific file.

See the Files Management article for examples.

Unfortunately, it's not possible to upload translations at the key level via CLI, this is limited by the Crowdin API.

[finebel]

@andrii-bodnar Thanks for the quick answer!

crowdin file upload seems to behave not 100% correct when used to upload translations. That's why I thought it was designed to only upload source string files.

Everything below was tested with Crowdin CLI 4.7.0

I have the following demo project:

.
├── crowdin.yml
├── crowdin_credentials.yml
└── feature
    ├── de.lproj
    │   └── Common.strings
    └── en.lproj
        └── Common.strings

That's my crowdin.yml file:

"base_path": "."
"preserve_hierarchy": true

"files": [
  {
    "source": "/**/de.lproj/*.strings",
    "translation": "/**/%osx_locale%.lproj/%original_file_name%"
  }
]

Now I want to upload the English translations stored in feature/en.lproj/Common.strings. For this, I initially tried the following command:

crowdin file upload feature/en.lproj/Common.strings \
    --language en \
    --branch main \
    --identity crowdin_credentials.yml

However, this results in a failure:

❌ 'dest' parameter required to specify source file path

Based on the failure message, I specfied the source file path (feature/de.lproj/Common.strings):

crowdin file upload feature/en.lproj/Common.strings \
    --dest feature/de.lproj/Common.strings \
    --language en \
    --branch main \
    --identity crowdin_credentials.yml

This gives me another error:

❌ File '/feature/de.lproj/Common.strings' not found in the Crowdin project

The fix for this seems to be to prefix the source file path with the branch name:

crowdin file upload feature/en.lproj/Common.strings \
    --dest main/feature/de.lproj/Common.strings \
    --language en \
    --branch main \
    --identity crowdin_credentials.yml

This finally seems to work.

In the Files Management article you shared, it says:

If you omit the -d option, the file will be uploaded to the root directory with the same path as the source file.
(...)
To upload translations you need to specify the -l/--language option:
crowdin file upload locales/fr/messages.xml -d messages.xml -l fr
The -d/--dest option is the path to the file in Crowdin where the translations should be uploaded.

Based on that, I would have thought that I don't need to specify the -d/--dest parameter at all when I want to upload the file to the same location under which it's stored in the local project. In any way, it seems like a bug that I have to prefix the (source) path with the branch name.
What's your take on this?

[andrii-bodnar]

Thanks for providing the details!
It is indeed a bug related to the --dest parameter and a branch name.

[finebel]

Thanks for the info! 🙌

Two follow-up questions:

1. Do you have a rough timeline for when this will be fixed?
2. The expected behaviour is to not need any --dest parameter when you want to use the path under which the file is stored in the local project, correct?

[andrii-bodnar]

First, we will address the issue of passing a branch name as a destination path prefix. The branch name should be passed only through the --branch parameter. We expect the issue to be resolved by the end of May.

not need any --dest parameter when you want to use the path under which the file is stored in the local project

This would be a nice enhancement, but it will be done separately.

[finebel]

One more question regarding the crowdin file upload command:

Based on my experiments, the --cleanup-mode and --update-strings options have no effect when being used in the context of translation uploads. When --cleanup-mode is specified, removed translations in the uploaded file don't cause the translations (or source strings) to be removed in Crowdin and even without the --update-strings option, translations with the same identifier are still being updated.
For me, that's currently not problematic - I just want to check whether the above is the expected behaviour.

[andrii-bodnar]

These parameters only apply to source files uploaded to String-based projects and do not affect file-based projects.

[finebel]

Thanks for the info! 🙌

Just as a suggestion: I think it would make sense to state this in the documentation.