iLib-js/loctool

Issue with merge losing previous translations

Closed this issue · 4 comments

I understood from the documentation that I should be able to cycle round, extract, translate, merge etc.

However if I merge in my translated xliff files (two languages) to the master one ProjectName.xliff
when I run loctool again it creates the correct language specific files for each language

BUT if I then make changes, get the new xliff files and translate those

When I merge the second or future xliff files into the Project one it does not merge it appears to just replace the existing content and then I have lost all my translations I did before and only have the most recent ones

I thought the merge was not just of the multiple languages into one - but of additional changes going forward
Am I miss understanding ?

Hi Peter, the merge functionality of the loctool is for convenience. The loctool now has a feature where it can read a directory full of translated xliff files, so you don't need to merge them anymore.

To use the directory of translations method, add the "xliffsDir" setting in your project json:

{
  "name": "myproject",
  "id": "myproject",
  "projectType": "custom",
  "settings": {
    "xliffsDir": "translations"
  }
}

Then put all your translated xliff files into the "translations" dir, giving each batch a unique name. If it starts getting slow to read that many translation files, you can merge them into a smaller number of files with the merge functionality.

So:

Step 1, run the loctool and generate the myproject-new-*.xliff files and send them out for translation.
Step 2, get the translations back and rename them to myproject-batch1-*.xliff and put them in the translations folder.
Step 3, run the loctool again, and you should have all your translations available to write into your resource files.

The translations dir will end up looking something like this:

myproject-batch1-de-DE.xliff
myproject-batch2-de-DE.xliff
myproject-batch3-de-DE.xliff
myproject-batch1-fr-FR.xliff
myproject-batch2-fr-FR.xliff
myproject-batch3-fr-FR.xliff
etc.

You can see how it might become unwieldy with only a few batches. Hence, the merging..

One idea I had for the loctool is to manage batches better. That is, automatically figure out what the next batch number is, so that instead of producing "new" files, the files with the new strings have the name "batch1" or "batch2", etc., sequentially. That way, when the translators are finished translating the files, you can just download the results into the translations dir as-is and check them in. Then, if it becomes too unwieldy or too slow to read all those files, you can merge them whenever you want.

Some other thoughts:

If you are using xliff v2.0 format files, they cannot have multiple locales in them, whereas v1.2 format files can. Merging multiple languages together will result in missing translations.

The merge tool does not merge translations into an existing file. Instead, it always creates a new output file.

loctool merge new-output-xliff old-translation-xliff latest-batch-translation-xliff

I should probably make the documentation more clear about that, and/or support merging a files into an existing file to rewrite it.

Edwin

Thanks for the quick reply and excellent work on this tool.

I had found the "xliffsDir" (and xliffsOut) variable from running in trace mode so I had my xliff files in another directory, but had not found the functionality to use multiple files.

Having tested this it works to provide just I was looking for.
It appears I don't need to call them 'batchx' just any file in the format "myProject-anything-locale.xliff", is that correct ?
I was thinking I may name them more related to a release rollout than just batch1,2,3

An update on the documentation around these variables and behaviour would be helpful for a newbee like myself who might otherwise have missed out on the capability of the tool.

Merge tool will be useful for managing multiple batch files as time moves on. With clarity on the fact the 'new' one is new and mot a merge with the others I don't think that is a big issue, but would be nicer if it merged if it existed already

My intention is using this to translate documentation written in Markdown and using Hugo. The ghfm plugin is close but I would look to see if I can do a more specific variant to ignore the shortcodes hugo uses as well.

Thanks for your assistance, happy to close ticket but would ideally like documentation tweaked.

You're right! I should fix the documentation for this. It's a hidden feature without it!

PR for the docs update: #128