Marker File (*_4loc.txt) for Source Files (*.txt)

Hi all,

We are using the GitHub integration to import regular text files containing a key-value pair per line. Since our repository contains many other text files that are not translation relevant we created empty file markers in the past with the only purpose to mark the source file as “relevant for translation”.

In other words, we have something like:

  • relevant.txt
  • relevant_4loc.txt
  • irrelevant.txt

Is there a way to search for _4loc.txt files and import the respective .txt files without importing the irrelevant ones. I did not find a way with the plain GitHub integration and also not with the pre-import plugin which seams to treat each file sandboxed.

Any ideas?

Thanks a lot and best regards, Dominic

1 Like

Hi Dominic,

If I got you right, the simple source/translation file path editing would work for you.

To include only specific files like _4loc.txt for translation and exclude others, you can utilize the source parameter in your Crowdin configuration file to define patterns that match the files you want to import from GitHub.

You can either include only relevant_4loc.txt into the source path (can be multiple) or exclude all other files while keeping the source path default.

Would that work for you?

2 Likes

Hi Dima,

thanks for the quick response!

The XXX_4loc.txt file is empty, it’s only the marker for the file XXX.txt to be for translation. Simply said: I want the import to know: If there is a *_4loc.txt file, I consider *.txt for import, otherwise ignore that file.

I did not find a way to import the *.txt file based on the existence of the respective *_4loc.txt. In previous solutions, we filtered all txt files to have a set of _4loc.txt files and then imported their respective “base” files, the ones without _4loc.txt.

Is it a bit clearer now?

Best regards, Dominic

Hi @dominicb,

Thank you for the clarification. Currently, our platform does not support conditional imports based on the presence of a marker file. The only solution would be, as Dima already mentioned in the previous message, to use the “ignore” option in the configuration file

2 Likes

Hi @Roman,
many thanks for your quick response!

Is it planned to add a feature to allow conditional imports? If not, is it possible to get access to resources on file system level? An optimum would be to have access to the resources right after syncing from GitHub and before the actual import. I saw there are a few apps available in the store that allow to modify files before import (e.g., Crowdin Enterprise). But as far as I can see they are on per-file level.

Should it be possible to implement my own app that can make use of the existing GitHub integration and prepares the files to our needs (remove those without _4loc identifier) before importing them?

Best regards, Dominic

1 Like

Hi @dominicb !

Sorry, but conditional imports are not currently a feature. If you are using the GitHub integration you may specify the conditions of the import directly in your configuration file as my colleague mentioned before. You may use the ignore parameter and also specify the source file path according to your needs.

Just to be with you on the same page. Could you please describe once again the desired result you want to get and why the proposed solution doesn’t cover your needs?

Thanks in advance!

2 Likes

Hi @Tania,

got it, it’s not a feature right now. But is conditional import planned to become a feature?

Here the description summarized:

  • We import from GitHub
  • We have many *.txt files
  • Those relevant for translation are marked with *_4loc.txt, for example strings_4loc.txt
  • Those NOT relevant for translation don’t have the 4loc, for example license.txt

In our repository, we have about 22,500 txt files; about 18,000 of them are translation relevant (~1,300 are marked with _4loc, the remaining 16,700 are translated files).

Following the approach of maintaining an ignore-list would mean to maintain a list of ~4,500 files which is highly error prone. That’s why it’s not really an option for us.

There is another alternative: Moving all the content of these files to the 4loc file and take this as source, i.e., filter for _4loc.txt and import only those. However, this would mean to implement many changes on product side.

That’s why we are looking for an approach to perform conditional imports, either via already existing app or by implementing a custom app, if possible.

I hope it’s a bit clearer now?

Best regards, Dominic

1 Like

Dear @dominicb !

Thank you for the explanation! For this purpose we recommend using patterns to import only specific files. Please kindly take a look at the attached article:

If additional assistance is needed please let us know!

1 Like

Hi @Tania,

using patterns would only help if the _4loc.txt files contain the strings to import? In our case _4loc files are empty, the files with no marker contain the strings, here an example:
image

This is not possible with patterns only, right?

Best regards, Dominic

Hi @dominicb
Just to be on the same page, you mentioned that files with the *_4loc.txt is relevant for translations and should be imported to Crowdin, so they shouldn’t be empty, am I right?

So with the patterns you can import only *_4loc.txt files for localization

Could you please give it a try and let us know about the result?

1 Like

Hi @Tetiana,

you mentioned that files with the *_4loc.txt is relevant for translations and should be imported to Crowdin, so they shouldn’t be empty, am I right?

No, *_4loc.txt files are EMPTY. A *_4loc.txt marks the respective companion txt file as relevant for translation. See my examples above.

Here another one:

  • If there is a abc.txt and a file abc_4loc.txt → Import abc.txt
  • If there is a def.txt nut NO def_4loc.txt → Don’t import def.txt

Best regards, Dominic

@dominicb I’ll double-check everything from my side and update you ASAP

1 Like

Hi @dominicb,

Just a quick update on this topic. The development team has confirmed that we do not have any apps that could help with your case and cannot do anything from our side. Your approach is unconventional

On your end, you can try writing a custom script that will regenerate the configuration file for integration

1 Like

Hi @Roman,

thanks for confirming!

On your end, you can try writing a custom script that will regenerate the configuration file for integration

Just to make sure: You mean to recreate the configuration.yaml file whenever needed, for example right before every import, right?

Hi Dominic, yes, you’re correct

1 Like

Thank you all for your help and your input! :slight_smile: