Empty directories are created on crowdin
Describe the bug The documentation says: "By default, directories that do not contain any files for translation will not be created in Crowdin." (https://support.crowdin.com/configuration-file/#saving-directory-structure-on-server)
To Reproduce Steps to reproduce the behavior:
- Configuration file with absolute base_path and a source path relative to the base-path that starts with /a/b/c/file.* where a, b and c contain no files
- Execute CLI command: upload
- See all directories /a/b/c have been created in crowdin
Expected behavior The behavior (as explained in the documentation) used to be that only /c is created
Environment:
- OS: Ubuntu
Hi @simonbethke!
Have you tried to set the preserve_hierarchy config option as false?
Hi, no I have not tried that. Actually, we have a static configuration that has not changed. Every month we upload the files and half a month later download the translations. Due to our code-repository I know that the config has not changed, but suddenly all of our source files are duplicated on crowdin in different folders. Somewhere either in this client or in the crowdin server a breaking change must have happened. Unfortunately I am not entirely sure, which version of the client has been used when.
@simonbethke probably the files structure was manually changed in Crowdin or the Crowdin CLI configuration was changed.
Could you please provide the details of how you usually upload files for translation to Crowdin?
In the company I am working at, we have a crowdin.yml very similar to this one:
"project_id" : "123456"
"api_token_env" : "CROWDIN_PERSONAL_TOKEN"
"base_path" : "/srv/application"
"base_url" : "https://api.crowdin.com"
"preserve_hierarchy": true
files: [
{
"source" : "/some/path/lang/de/*.ini",
"translation" : "/some/path/lang/%two_letters_code%/%original_file_name%",
"ignore" : ["/**/file1.ini", "/**/file2.ini"]
},
{
"source" : "/some/path/lang/de/subfolder/*.ini",
"translation" : "/some/path/lang/%two_letters_code%/subfolder/%original_file_name%",
},
{
"source" : "/other/some/path/lang/de/*.ini",
"translation" : "/other/some/path/lang/%two_letters_code%/%original_file_name%",
"ignore" : ["/**/file1.ini", "/**/file2.ini"]
}
]
We then enter the bash in a ubuntu docker-container and run the command "crowdin upload" from the folder /srv/application were also the crowdin.yml is located.
The resulting file-structure on crowdin used to be:
- lang
- de
- subfolder / (with files)
- (more files)
- de
- other
- some
- path
- lang
- de (with files)
- lang
- path
- some
Now after the last upload, the structure on crowdin was suddenly:
- some
- path
- lang
- de
- subfolder / (with files)
- (more files)
- de
- lang
- path
- lang
- de
- subfolder / (with files)
- (more files)
- de
- other
- some
- path
- lang
- de (with files)
- lang
- path
- some
@simonbethke thanks for the details provided!
It looks like the preserve_hierarchy previously was false and now it's true.
Which version of Crowdin CLI you are using? Did you change the version to another one and the behavior changed?
There might have been a version update. Unfortunately this is something I cannot find out easily. What I know is, that this issue occurs in the latest version and also, I am 100% sure that the preserve_hierarchy parameter has been true all the time. This file is in our version control, and the last change in this line was about 1year ago.
@simonbethke could you please try to check on the 3.7.7 version of CLI?
Just tried that, same issue.
@simonbethke maybe the working directory was changed? The directory from which the CLI running
or the project files structure was changed?
No, the working directory still is and always has been the same. If I can find any mistake on our end, I will post it here, but for the moment I suggest to keep this issue open or migrate it to the bug-tracking of the crowdin platform itself? I was not able to find any bug-tracker for crowdin itself. Maybe there has been an internal server-side release that I am not aware of.
@simonbethke this issue can be tracked here
There were no updates on the server-side that could affect the files upload, it's very strange.