Why Angular uses XLIFF 1.2 instead of XLIFF 2?

Question

I'm starting a new Angular 6 project (and I'm new to Angular as well ^^) so I am pretty free about the choices. When coming to Internalization, we chose to use Angular native I18n after reading:

• ngx-translate author answer on ngx-translate vs native I18n
• why XLIFF is a relevant format for I18n

The fact that translations cannot be used out of template files can be fixed by some workaround at our stage

XLIFF learning curve hit me with the question of XLIFF 1.2 vs XLIFF 2. After reading the differences between XLIFF 1.2 and XLIFF 2, it seems that XLIFF 2 solved a lot of issues and is more future-proof than XLIFF 1.2 which is now a legacy format according to Wikipedia

Consequently, why Angular is focused on XLIFF 1.2 instead of XLIFF 2? I noticed that:

• The official Angular I18n uses XLIFF 1.2
• Most of web resources (like on Medium) use XLIFF 1.2
• It's pretty hard to find some free translation tools compatible with XLIFF 2 (I got error when importing XLIFF 2 file on SmartCat and I struggled with Rainbox/Okapi framework)
• It's also pretty hard to find help on XLIFF 2 (like how do I do the ICU stuff?), at least for a beginner

---

As for our project, we started on XLIFF 2 but I'm strongly tempted to switch to XLIFF 1.2

Broddie

github.com/angular/angular/issues/24315 There seems to be a way to use xliff 2 – Ison

Updated way to use XLIFF2 or another format is the --format option: angular.io/cli/extract-i18n – Entitle

Answer 1

Your question is quite subjective as to why, but Angular isn't alone. XCode also still uses XLIFF 1.2. Symfony recently added v2 support, but the docs still reference 1.2.

I think adoption has been slow amongst web frameworks because the format doesn't add much in the way of capabilities that web frameworks were lacking before. It provides lots of scope for extensibility, but as great as that sounds it just means people can use the format any way they see fit. I mean <note category="file-source">file.js:93</note> is great, except that "file-source" isn't part of the spec so not very cross-platform.

Perhaps the format is doing better within the translation industry, but web frameworks don't tend to use many of the format's advanced features. For the most part XLIFF files are used as fairly dumb containers for indexing strings and v1.2 does that as well as v2 does.

If a framework was starting fresh XLIFF 2 seems like a no-brainer, but if you already have thousands of people happily using 1.2, I don't think there's a huge motivation to upgrade.

My advice would be to ensure you can always switch file formats if you need to. Use 1.2 by all means if it gives you access to tools you like, but if Angular one day decides to deprecate 1.2 and move to v2 you'll need to have a plan. There are editors out there that support both formats.

Hexachord

Answer 2

Angular is now accepting XLIFF 2 files (see here)

Rosyrot

Answer 3

I'd like to point out that line from the official specification changelog for 2.0:

In response to comment 002, the specification now clearly indicates that backwards compatibility with XLIFF 1.2 is not required.

You can also read from the same changelog :

In response to comment 038, modules, , and extensions have been prohibited on and lower structural levels.

So a file might not validate both format.

Glenglencoe