Here is an with two tag within its source and target.

<trans-unit id="8856d298b6fa89a339475c5d5cd20f2d2afcfbf7" datatype="html">
  <source>New <x id="START_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element" equiv-text="&lt;bs-activity-stream-element>"/><x id="CLOSE_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element" equiv-text="&lt;/bs-activity-stream-element>"/> was reported by <x id="START_TAG_BS-ACTIVITY-STREAM-ELEMENT_1" ctype="x-bs-activity-stream-element" equiv-text="&lt;bs-activity-stream-element>"/><x id="CLOSE_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element" equiv-text="&lt;/bs-activity-stream-element>"/></source>
  <context-group purpose="location">
    <context context-type="sourcefile">app/elements/dashboard/activity-stream/elements-shared-activity-stream.component.ts</context>
    <context context-type="linenumber">127</context>
  </context-group>
  <target state="translated">新しい<x id="START_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element"/><x id="CLOSE_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element"/>によって報告された<x id="START_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element"/><x id="CLOSE_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element"/></target>
</trans-unit>

Look at START_TAG_BS-ACTIVITY-STREAM-ELEMENT in source and target. Former has correct START_TAG_BS-ACTIVITY-STREAM-ELEMENT and START_TAG_BS-ACTIVITY-STREAM-ELEMENT_1, whereas the latter has two START_TAG_BS-ACTIVITY-STREAM-ELEMENT (second one is missing "_1").

Here is the original line from the messages.xlf generated by xi18n tool

<source>New <x id="START_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element" equiv-text="&lt;bs-activity-stream-element&gt;"/><x id="CLOSE_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element" equiv-text="&lt;/bs-activity-stream-element&gt;"/> was reported by <x id="START_TAG_BS-ACTIVITY-STREAM-ELEMENT_1" ctype="x-bs-activity-stream-element" equiv-text="&lt;bs-activity-stream-element&gt;"/><x id="CLOSE_TAG_BS-ACTIVITY-STREAM-ELEMENT" ctype="x-bs-activity-stream-element" equiv-text="&lt;/bs-activity-stream-element&gt;"/></source>

And here is another problem - xliffmerge did not escape attribute value properly. Instead of

equiv-text="</bs-activity-stream-element>"

it printed

equiv-text="</bs-activity-stream-element>"

OS: Mac OS
Node: 8.4.0
Hi, This is my xliffmergeOptions, my default language is 'zh-CN', when I try to translate zh-CN to en with auto translation, I got the error message below:

{ "xliffmergeOptions": { "srcDir": "src/i18n", "genDir": "src/i18n", "i18nFile": "messages.xlf", "i18nFormat": "xlf", "encoding": "UTF-8", "defaultLanguage": "zh-CN", "languages": ["en", "ja"], "removeUnusedIds": true, "supportNgxTranslate": true, "useSourceAsTarget": false, "autotranslate": ["en"], "apikey": "***", "apikeyfile": "", "verbose": false, "quiet": false } }

ERROR: autotranslate language "en" cannot be translated, because it is the source language npm ERR! code ELIFECYCLE npm ERR! errno 255 npm ERR! [email protected] translate:file: ng xi18n --output-path src/i18n --locale zh-CN && xliffmerge --profile xliffmerge.json en ja`
npm ERR! Exit status 255
npm ERR!
npm ERR! Failed at the [email protected] translate:file script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/liuxinqiang/.npm/_logs/2017-08-29T09_08_49_961Z-debug.log`

Hi. it would be amazing if it supports 'en_US' language formats(not really sure what/if they have a name for that format). I can push a pr for this as it's just a small update.

I have my messages.xlf files (with "new" targets). I changed a i18n attribute from an explicit ID, i18n="@@myid", to autogenerated ID, and ran the tool. The target in the DE file is now in the "translated" state. It should remain "new". In fact, it should ignore all existing "new" targets when re-ID'ing.

This tool is great BTW. Love it.

Instead of giving all languages at the commandline, it should be possible to set them in the profile.

Before:
xliffmerge en de fr it

After:

xliffmergeconfig.json:
{..
  "languages": ["en", "de", "fr", "it"],
  ..
}
commandline:
xliffmerge --profile xliffmergeconfig.json

since the master messages.xlf doesn't contain a <target></target> tag anymore the tag is also missing in the generated file. So either the tool should create a <target state="new">Hello, world</target> (prefered by me; maybe make it configurable) or change the readme.

Thanks for the tool :)

After the build of milestone 0.1 the code coverage was only 40%, which is less than half as before.
This is not, what is shown locally, and it is definitely wrong.

It should be over 80%.

There are no trans units changed.
The message

' WARNING: transferred 28 source references from master to "de"'`

is just because of wrong counting.

Scenario was tiny-translator.
There is auto translation active for fr-google only:

{
  "xliffmergeOptions": {
    "srcDir": "src/i18n",
    "genDir": "src/i18n",
    "autotranslate": ["fr-google"],
    "apikeyfile": "googleTranslateApiKey.txt"
  }
}

When merging there are messages like:

WARNING: Auto translation from "en" to "ru-google", total auto translated units: 0, ignored: 0, succesful: 0, failed: 0

This is not wanted.

xmlifmerge is great, thank you so much for writing it.

One request I have is that when merging into existing language files, trans-units with the same id but with different description and meaning values could be updated with the new description and meaning.

I find that we do this once in a while where we get a question from a translator to clarify a given unit so we change the description text and want to get it into all the language files for all translators.

Is this something that could be supported?

The translation fails if an empty line is part of the translation.
ERROR: Auto translation from "en" to "de" failed: "Invalid request: Required Text", failed units: 0

We had this issue with HTML formatted like this:

<div i18n>
  text
</div>

This is not really recommended by ng xi18n so I am not sure if it is an issue - see:
angular/angular-cli#6941

The state of the translation is reset from final to translated so it was a problem in our case.

Thank you for this tool. I tried automatic translation to German and it seems to work well. But when I tried Arabic 'ar' no translation was done, just the source copied.

When you are using placeholder or linebreaks or embedded html in the messages, they seem to be handled somewhat special.

Examples:

<p i18n>Item {{number()}} of {{total()}} added</>
<p i18n>A line
  with a break</p>
<p i18n="embedded html sample">This text contains <b>embedded html</b></p>

Using the angular ng-xi18n CLI tool to extract i18n tags will produce this sample source file:

<xliff version="2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en">
  <file original="ng.template" id="ngi18n">
    <unit id="login.component-remember.checkbox.label">
      <segment>
        <source>Remember me</source>
      </segment>
    </unit>
  </file>
</xliff>

After running xliffmerge to produce German translated messages.de.xlf file I see this content:

<?xml version="1.0" encoding="UTF-8"?>
<xliff version="2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en" trgLang="de">
  <file original="ng.template" id="ngi18n">
    <unit id="login.component-remember.checkbox.label">
      <segment state="new">
        <source>Remember me</source>
      </segment>
    </unit>
  </file>
</xliff>

Please check the modified <segment state="new">, which is wrong XLIFF2 format. Only those four states are allowed:

• initial - indicates the segment is in its initial state.
• translated - indicates the segment has been translated.
• reviewed - indicates the segment has been reviewed.
• final - indicates the segment is finalized and ready to be used.

I guess there was a mix-up with old XLIFF 1.2 states. Please compare:

• http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#state
• http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html#state

I did not check if there is anything else is breaking further regarding this state.

Sidenote: this http://omegat.org translation tool was throwing an exception when trying to load an XLIFF2 file.

Hi

it looks like you published your npm package from a windows machine, causing an issue on unix machines.
Can you fix this please, at the moment I did it by changing the file locally myself.
so you will need to convert CRLF to LF in src/xliffmerge/xliffmerge

Instead of having a separate configuration File it should be possible to write the configuration as Part of the package.json File.
A JSON schema for the configuration would be nice too.

There is a fixed issue in angular 4.3.2: XLIFF 2.0 file created by the extract tool misses equiv="ICU" angular/angular#17344.
ICU messages in XLIFF 2.0 now will have an equiv="ICU".
This must be handled correctly by the lib.
(which is not the case in the moment)

Hi, great looking package!
But on installation, npm throws the following error for me:

2023 error Linux 4.8.0-39-generic 2024 error argv "/usr/bin/nodejs" "/usr/bin/npm" "install" "ngx-i18nsupport" "--save-dev" 2025 error node v7.2.1 2026 error npm v3.10.10 2027 error path /home/nico/src/tradity-client/node_modules/ngx-i18nsupport/dist/xliffmerge/xliffmerge 2028 error code ENOENT 2029 error errno -2 2030 error syscall chmod 2031 error enoent ENOENT: no such file or directory, chmod '/home/nico/src/tradity-client/node_modules/ngx-i18nsupport/dist/xliffmerge/xliffmerge' 2032 error enoent ENOENT: no such file or directory, chmod '/home/nico/src/tradity-client/node_modules/ngx-i18nsupport/dist/xliffmerge/xliffmerge' 2032 error enoent This is most likely not a problem with npm itself 2032 error enoent and is related to npm not being able to find a file. 2033 verbose exit [ -2, true ]

Seems to me like you didn't publish the dist file on npm?

This new feature allows to auto translate new units using Google translate.
Idea: you enable it in configuration and set an API key like this

{
  "xliffmergeOptions": {
    "autotranslate": true,
    "apikey": "xxxghh23...",
...

and then every new unit will be created translated via Google translate.

Hi Martin!
Thanks a lot for this tool, and the TinyTranslator holy cow! super useful!

I wonder why after xliffmerge execution there remains some empty json files side by side with the localized files, like:

- messages.en-us.json
- messages.en-us.xlf
- messages.es.json
- messages.es.xlf
- messages.xlf

I will give you a hand with the TinyTranslator interface when i have spare time!
Thanks again!

I am using yarn, and was able to install the package using yarn add ngx-i18nsupport. However, subsequently running xliffmerge at the command line resulted in "Command not found." I tried closing my terminal and reopening in case the PATH needed to be updated, but it made no difference.

I'm not sure if this is related to installing via yarn instead of npm, something screwy in my path setup, or perhaps something else. For the time being, I have solved this by running with the relative path:./node_modules/ngx-i18nsupport/dist/xliffmerge/xliffmerge, which works but seems hackish.

If anyone has insight on why this might be happening I would be interested in hearing it.

By the way thank you for sharing the script @martinroob - it works wonderfully and solves a critical problem.

The following expression

<source>{VAR_PLURAL, plural, =1 {Crash <x id="INTERPOLATION" equiv-text="{{ activity.options.merged_string }}"/> was} other {Crashes <x id="INTERPOLATION" equiv-text="{{ activity.options.merged_string }}"/> were} }</source>

causes xliffmerge to fail with

non ICU message:  {VAR_PLURAL, plural, =1 {Crash <x id="INTERPOLATION" equiv-text="{{ activity.options.merged_string }}"/> was} other {Crashes <x id="INTERPOLATION" equiv-text="{{ activity.options.merged_string }}"/> were} } Error: Error parsing ICU Message: expected EOF, found TEXT ("/> was} other ) (message {VAR_PLURAL, plural, =1 {Crash <x id="INTERPOLATION" equiv-text="{{ activity.options.merged_string }}"/> was} other {Crashes <x id="INTERPOLATION" equiv-text="{{ activity.options.merged_string }}"/> were} })
    at ParsedMessagePartICUMessage.expectNext (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:6321:19)
    at ParsedMessagePartICUMessage.parseICUMessage (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:6310:14)
    at new ParsedMessagePartICUMessage (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:6262:15)
    at ParsedMessage.addICUMessage (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:6033:26)
    at XliffMessageParser.AbstractMessageParser.addPartsOfNodeToMessage (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:1446:29)
    at XliffMessageParser.AbstractMessageParser.createNormalizedMessageFromXML (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:1409:18)
    at XliffTransUnit.createSourceContentNormalized (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:5057:41)
    at XliffTransUnit.AbstractTransUnit.sourceContentNormalized (/Users/builder/app/node_modules/ngx-i18nsupport-lib/bundles/ngx-i18nsupport-lib.umd.js:1041:50)
    at /Users/builder/app/node_modules/ngx-i18nsupport/dist/autotranslate/xliff-merge-auto-translate-service.js:55:105
    at Array.filter (<anonymous>)

Starting with ng 4.0 there is a reference to the source of a message in the xlf or xmb file.
xliffmerge should transport this information from the master to the merged files.

This should happen too when the merged file contains already completed translations.

I'm using xliffmerge right now and I was wondering if the output could be more human readable. For example now it generates output like this:

<target state="new">Name:</target></trans-unit><trans-unit id="380b43f6f630204545ad0e23c206e97c5c4bdecb" datatype="html">
  <source>Reward:</source>
        
<target state="new">Reward:</target><context-group purpose="location"><context context-type="sourcefile">example.component.ts</context><context context-type="linenumber">37</context></context-group></trans-unit><trans-unit id="ea71da1aed0ad121e79a8e73c0d66ec10c52e36d" datatype="html">  <source>Number of uses:</source>
        
<target state="new">Number of uses:</target><context-group purpose="location"><context context-type="sourcefile">example.component.ts</context><context context-type="linenumber">50</context></context-group></trans-unit><trans-unit id="3c02902d1e6bc749c646f88b6f7d3e019440df63" datatype="html">

While I would appreciate it to be more like this:

  <target state="new">Name:</target>
</trans-unit>

<trans-unit id="380b43f6f630204545ad0e23c206e97c5c4bdecb" datatype="html">
  <source>Reward:</source><target state="new">Reward:</target>
  <context-group purpose="location">
    <context context-type="sourcefile">example.component.ts</context>
    <context context-type="linenumber">37</context>
  </context-group>
</trans-unit>

<trans-unit id="ea71da1aed0ad121e79a8e73c0d66ec10c52e36d" datatype="html">  
  <source>Number of uses:</source><target state="new">Number of uses:</target>
  <context-group purpose="location">
    <context context-type="sourcefile">example.component.ts</context>
    <context context-type="linenumber">50</context>
  </context-group>
</trans-unit>

<trans-unit id="3c02902d1e6bc749c646f88b6f7d3e019440df63" datatype="html">

The output is correct of course but it's a little tedious to translate this right in the xlf file.

Our languages are country specific, so instead of en we have e.g. en_US. This does not seem to be supported right now, as with the following...

{
...
"languages": ["en_US"],
...
}

... I receive

$ node_modules/.bin/xliffmerge -p .xliffmerge
ERROR: language "en_US" is not valid

Hello, when using this lib to handle the xmb format, it generates the correct source messages.xmb, but then for each locale to translate it will create a new translations file in xmb (ex: messages.xmb --> messages.fr.xmb).
The correct translation files for xmb are in the xtb format, and the syntax is different (messagebundle is now translationbundle, msg elements are now translation elements, ...).
This lib should create correct xtb files for the translations.

I can't install this module because of the following error:

ENOENT: no such file or directory, chmod '...\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliffmerge'

It looks like maybe the latest npm was published without the dist folder?

Is there a simple way to merge two source file -- messages.xlf -- into one? I'm guessing a setting could determine which file takes precedence when they both have the same translation id.

Hi and thanks for xliffmerge!

When xliffmerge changes a translation file, the trailing line break is removed. This is a bit annoying in the workflow because you need to revert the change manually.

The first diff is expected, the second is not.

The problem does not occur if there is no change in the translation.

I'd be a really nice feature to support conversion among the supported file formats (including conversion of message ids). In fact, there is probably no simple way to migrate from xliff 1.2 to xliff 2.0 at the moment.

'xliffmerge --version' shows 0.0.1.
The correct version should be read from package.json

Running the example config from the README, I receive the following output:

$ node_modules/.bin/xliffmerge -p .xliffmerge
ERROR: oops SyntaxError: Unexpected token } in JSON at position 349
~/my_project/node_modules/ngx-i18nsupport/dist/xliffmerge/xliff-merge.js:91
                throw err;
                ^

SyntaxError: Unexpected token } in JSON at position 349
    at JSON.parse (<anonymous>)

It should be possible to use the main classes (XliffFile ...) as a class library from other classes.
(I want to use that mainly for the tiny-translator project).

Next problem:
TypeError: rx_http_request_1.RxHR.post(...).map is not a function
at AutoTranslateService.limitedTranslateMultipleStrings (S:\experimente\tiny-translator\node_modules\ngx-i18nsupport\dist\autotranslate\auto-translate-service.js:88:62)
at S:\experimente\tiny-translator\node_modules\ngx-i18nsupport\dist\autotranslate\auto-translate-service.js:37:26

Does not happen during all tests, what a mess!

xliffmerge -v --profile ./xliffmerge.json ru-RU

• xliffmerge version 0.13.0
• xliffmerge Used Parameters:
• defaultLanguage: "en-US"
• srcDir: "src/i18n"
• genDir: "src/i18n"
• i18nBaseFile: "messages"
• i18nFile: "src/i18n/messages.xlf"
• languages: ru-RU
• outputFile[ru-RU]: src/i18n/messages.ru-RU.xlf
• removeUnusedIds: false
• supportNgxTranslate: false
• useSourceAsTarget: true
• targetPraefix: ""
• targetSuffix: ""
• allowIdChange: false
• autotranslate: true
• autotranslated languages:
• apikey: ****
• apikeyfile: null
• master contains 415 trans-units
• processing language ru-RU
• created new file "src/i18n/messages.ru-RU.xlf" for target-language="ru-RU"
  WARNING: please translate file "src/i18n/messages.ru-RU.xlf" to target-language="ru-RU"

Ng I18n only supports static translation of texts used in the templates.

To be able to use translations in services, pipes, ..., you can use ngx-translate.

But this needs json-data-files as inputs.

xliffmerge should be able to generate such data files based on the i18n texts used in the templates.
To get keys usable for ngx-translate use the intent and description parts, intent is used as the key, description must be ngx-translate, e.g.

<p i18n="myapp.example.hellotext|ngx-translate">Hello world!</p>

will eventually create a file data.en.json

{
  "myapp" {
    "example": {
      "hellotext": "Hello world!"
    }
  }
}

and this file can be used by ngx-translate

Every errormessage should at least show the file, that initiated the error.

First, Thanks for the tool. One of my use for the tool is to verify that all displayed string in UI are part of i18n xliff. So I want in target language file, all the texts should have a prefix so that I will know that texts which miss translation. For example, in english, I have a string 'menu" in UI, then once I load a test language, I see that the caption is changed to '%%menu'. So can we have an option to add prefix in the target languages?

Similar too #44.
If the ID is explicitly set but you change the source message, this change should be merged into the translation files.
Status of trans-unit should then be set to "TRANSLATED" if it was "FINAL" before.

The angular team design doc about xliff serialization mentions the possibilty of settung explicit IDs with markup like this:

<p i18n="mmm|ddd@id">...

This should be used for the ngx-translate-support.

Also take issue i18n: Able to use translation strings outside a template into account.

TypeError: Cannot read property 'map' of undefined
at XliffMerge.processLanguage (S:\experimente\tiny-translator\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge.js:220:13)
at S:\experimente\tiny-translator\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge.js:132:49

For generating .json files for ngx-translate, xliffmerge now looks at both i18n="my.app.key|ngx-translate" and i18n="@@my.app.key" as markers which entries to include in the generated .json files. The latter (i18n="@@my.app.key") is also used by the angular-cli extraction tool to use fixed ID's for the entries in the translation file. So these entries now also popup in the json files for ngx-translate where I don't need them.

So please only use the first syntax (i18n="my.app.key|ngx-translate") for selecting the entries for the ngx-translate json files.

We are using the approach outlined in the merge guide:
ng xi18n --output-path src/i18n --locale en && xliffmerge --profile xliffmerge.json en fr

When the source text is modified the en file that is updated only has the source update not the target even though the source language is en. Here is an example of how to reproduce it:

HTML:

<div i18n="@@fooTag">This is new text</div>

Produces these files:
messages.xlf

<trans-unit id="fooTag" datatype="html">
    <source>This is new text</source>
</trans-unit>

messages.en.xlf

...
<file source-language="en" target-language="en">
...
<trans-unit id="fooTag" datatype="html">
    <source>This is new text</source>
    <target state="final">This is new text</target>
</trans-unit>

messages.fr.xlf

...
<file source-language="en" target-language="fr">
...
<trans-unit id="fooTag" datatype="html">
    <source>This is new text</source>
    <target state="new">This is new text</target>
</trans-unit>

This works as expected. But then later if the HTML is modified like this:

HTML:

<div i18n="@@fooTag">This is modified text</div>

Produces these files:
messages.xlf

<trans-unit id="fooTag" datatype="html">
    <source>This is modified text</source>
</trans-unit>

messages.en.xlf

...
<file source-language="en" target-language="en">
...
<trans-unit id="fooTag" datatype="html">
    <source>This is modified text</source>
    <target state="translated">This is new text</target>
</trans-unit>

messages.fr.xlf

...
<file source-language="en" target-language="fr">
...
<trans-unit id="fooTag" datatype="html">
    <source>This is modified text</source>
    <target state="new">This is new text</target>
</trans-unit>

You can see in the en file that the target is not update to reflect the new text, and for some reason the state changes from final to translated

Hi Martin,

i just found out, that the position of "older" trans-units only gets updated if there is a new trans-unit created by ng-xi18n first.

Maybe it would be possible to update while iterating over the nodes and comparing ids.

Since Angular 4.0 there is a source element in xliff and xmb files.

It contains the template file and position, where the text is contained.
There shoUldale be an api to access it and it should be handled correctly.

Tiny translator should even show it.

Additional to xlf (XLIFF) the xmb format should be supported too.

Running xliffmerge on a <trans-unit /> that has had anything in the <context-group/> tags changed causes all the contained <context-group /> tags to collapse into one line with the <target /> tag. Changes such as line number and new context location trigger this consistently for me.

This can cause a lot of git changes to the files and causes inconsistencies with newly generated files.

The workflow should be demonstrated in form of a tutorial.

Something like

• create an app
• add some i18n texts
• translate
• modify the app
• translate again

Hi,

I'm trying to use the xliffmerge tool with the profile but get the error below, am I doing something wrong?
I'm using the lastest version v0.7.4

xliffmerge --profile xliffmerge.json

undefined:1
{
^

SyntaxError: Unexpected token  in JSON at position 0
at JSON.parse ()
at XliffMergeParameters.readProfile (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge-parameters.js:76:21)
at XliffMergeParameters.configure (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge-parameters.js:37:35)
at Function.XliffMergeParameters.createFromOptions (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge-parameters.js:24:20)
at XliffMerge.doRun (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge.js:107:77)
at XliffMerge.run (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge.js:87:14)
at Function.XliffMerge.main (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\xliff-merge.js:29:85)
at Object. (C:\Users\Username\AppData\Roaming\npm\node_modules\ngx-i18nsupport\dist\xliffmerge\main.js:8:26)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)

xliffmerge.json:

{
  "xliffmergeOptions": {
    "srcDir": "src/i18n",
    "genDir": "src/i18n",
    "i18nFile": "messages.xlf",
    "i18nFormat": "xlf",
    "encoding": "UTF-8",
    "defaultLanguage": "en",
    "languages": [ "en", "nl", "fr", "de" ],
    "removeUnusedIds": true,
    "supportNgxTranslate": true,
    "useSourceAsTarget": false,
    "autotranslate": false,
    "apikey": "",
    "apikeyfile": "",
    "verbose": false,
    "quiet": false
  }
}

Starting with the newest angular release (4.0.3) the XLIFF 2.0 format is available.
(angular/angular#11735).
We should support this too.