Description
Url: http://symfony.com/doc/current/best_practices/i18n.html
The Original Best Pratices
- Use the XLIFF format for your translation files.
- Always use keys for translations instead of content strings.
Best practice 2 ("Store the translation files in the app/Resources/translations/ directory.") is not included in this RFC.
The Proposed Best Practices
- Use the Yaml format for your translation files.
- Always use keys for translations instead of content strings
Reasoning
-
The Translation component hardly supports the Xliff specification. Actually, it reads just
<source>,and` elements and everything else is ignored. The Xliff specification contains a lot more elements which are usefull for translations. As such, the Xliff format is not the way it's intended by the Xliff specifications. Some examples (I've left out all boilerplate code):Please note that I don't consider myself a Xliff expert, far from that. The examples might be invalid, but they create a picture to illustrate the difference between Xliff's intended approach and Symfony's Xliff implementation
The Symfony Way
<source>Hello %name%!</source> <target>Hello %name%!</target>
The Xliff Way
<source>Hello <g id="1">name</g>!</source>
The Symfony Way
<trans-unit id="apples"> <source>I have %number% apples</source> <target>{0}I have 0 apples|{1}I have 1 apple|[2,Inf]I have %number% apples</target> </trans-unit>
The Xliff Way
<group restype="x-gettext-plurals" id="apples"> <trans-unit id="apples[0]"> <source>I have no apples</source> </trans-unit> <trans-unit id="apples[1]"> <source>I have one apple</source> </trans-unit> <trans-unit id="apples[n]"> <source>I have <g id="1">count</g> apples</source> </trans-unit> </group>
Besides these, there are many other examples. For instance, doing something with the attributes of the
<file>and<body>elements. -
The Translator does not support anything more than a key-value pair. It seems completely against all DX conventions to have so much boilerplate code for just a simple key-value representation
-
Using keys as the source is against the Xliff specification goals. If the best practice still want to recommend Xliff, it the other best practice should be changed to "Use the messages itself as the source/key"
-
XML is a difficult format. This makes it hard for beginners to understand. Besides that, DTD errors are hard to read if you aren't used to them. As demostrated in Improve an error message related to Xliff translation files symfony#11256, using simple HTML entities like
…will cause errors. And those errors cause headaches to understand what's wrong and how to fix it.