Filter_type: dir not syncing from GH to Transifex

I have a project (Github link, Transifex link) which is set up to sync with Transifex.

All the ’filter_type: file options work, however, I’m now trying to localize more files with the filter_type: dir option by adding it to my transifex.yml file. However, after fiddling with the config file, I can’t get any of the original resource files to sync from GitHub → Transifex.

Here’s the relevant info:

Relevant Config:

    - filter_type: dir
      translation_files_expression: 'Quicksilver/Nibs/<lang>.lproj'
      source_file_dir: Quicksilver/Nibs/en.lproj
      source_file_extension: strings
      file_format: STRINGS
      source_language: en_US

(I tried adding trailing slashes to the source_file_dir and translation_files_expression options, but that didn’t work either).

Original (Base Language) Files: Quicksilver/Nibs/en.lproj/*.strings (view files)
Translated Files: Quicskivler/Nibs/<lang>.lproj/*.strings

Screen Region 2022-05-03 at 09.20.02

Note: All the ‘single file’ resources are getting synced fine, it’s just this new filter_type: dir option that’s not working.

OK, so one of my .strings files just synced, but not the other ones. I have 3 .strings files all together here: Quicksilver/Quicksilver/Nibs/en.lproj at main · quicksilver/Quicksilver · GitHub

The ResultWindow.strings file has synced, but not the other two. What is it about the other two files that means they can’t sync?

Hello @pjrobertson ,

Thank you for reaching out to the Transifex community.

I will take a closer look at this and I will reply as soon as possible.

Kind regards,

Hello @pjrobertson ,

After further investigation of your examples, I realized two issues.

The first one is related to the structure of your developer notes which are in the following way.

/* Class = "NSWindow"; title = "Quit?"; ObjectID = "23"; */
"23.title" = "Quit?";

Unfortunately, this is not accepted by our parser. You can restructure the comments like the following way, without the ; character.

/* Class = "NSWindow" title = "Quit?" ObjectID = "23" */
"23.title" = "Quit?";

OR separate them in the following way

/* Class = "NSWindow"; */
/* title = "Quit?"; */ 
/* ObjectID = "23" */
"23.title" = "Quit?";

Apart from this, I can see that in your file the source language is en_US.
So, you need to change the following parameter

source_file_dir: Quicksilver/Nibs/en.lproj

as the following

source_file_dir: Quicksilver/Nibs/en_US.lproj

I tested this on our side, and it works as it should.

Please let me know if you have any further questions.

Kind regards,

Hi Panagiotis, thanks for the investigating!

Unfortunately, this is not accepted by our parser. You can restructure the comments like the following way, without the ; character.

I suggest you update the parser to accept this format. This is auto-generated by Xcode when the ‘Localize’ button is clicked (under the hood, Xcode uses ibtool --export-strings-file). As such, I don’t think I will be the only one experiencing the same problem. If I were to go in and manually change the format, then Xcode would just over-write them on the next save.

Regarding the 2nd issue, there is a mapping for en > en_US here - that works for all other files (they just use the en.lproj format) so that’s not the issue I guess. I assume the main issue is the first one you listed.

Hopefully the parser can be updated to accept semicolons in the comments!

Hi again @Panagiotis_Kavrakis , I’ve been investigating this further, and the good news is I don’t think the issue is the one you mention with the ; character. Please note that this file was synced no problem, and you’ll note that the original file is also in the same file format (as produced automatically by Xcode).

However, I’m still not clear as to why the ResultWindow.strings file was able to sync, but not the others.

Hello @pjrobertson ,

Thank you for your messages. I investigate further the files you shared, and indeed the actual problem was not the character ‘;’. I apologize for my previous explanation even if this was shown as the most possible after my testing previously.

The actual problem is the type of the newlines inside the files.

For example, the following file uploads successfully, when you are using LF

but it fails to be uploaded if you are using CRLF

I have already forwarded this to our developer’s backlog list. Once I have an update I will let you know. As a workaround, it could be to change the CRLF → LF in your files, in order to be parsed successfully.

As far as the other question, about the language mapping, at the moment it works only for the target languages and not the source language. Also, I would like to mention here, that the 2 different types (file VS dir) work in a different way that’s why you get the files you want from the en.lproj folder when you are using the file type instead of dir.

However, I have also included your request to our product team for further evaluation, and we really appreciate this.

Please let me know if you have any further questions.

Kind regards,

Thanks for the reply, Panagiotis.

However I still don’t think that’s quite the issue. I checked the two files that are not being synced, and they both had the same LF characters.

I investigated further, and I managed to get one file (QuitWindow.strings) to sync after removing the ‘?’ from the comment: Attempt to fix transifex syncing issue · quicksilver/Quicksilver@9fbb11f · GitHub

And that worked. So I suggest you feedback that back to your developers, that comments with ? in them seem to be breaking the parser.

Now for the final file here - I’m still trying to work out what string is breaking the parser. There are no ? in here.

Hello @pjrobertson ,

Thank you for your reply.

I tried to upload the following file where both LF and the character ‘?’ exists in the comments and it uploaded successfully as you can see below.

And here is what it looks like in the editor.

However, If you tried to upload the following file with CRLF

you can see that it fails

So, I am not sure that the issue is the character ‘?’ in the comments.

Looking forward to your response.

Kind regards,