Imo, the error is spot on. However, there are other problems:

1. Most developers have no advanced XML knowledge and don't understand these pretty advanced XML errors
2. Most people don't understand the Xliff format
3. Twig always want to have the last word and thus always repeat the previous exception.
4. Symfony has a far from complete Xliff loader

Because of (1), (2) and (4), Symfony should recommend to use the more simpler Yaml translation files instead of Xliff. In the usage of Symfony, Xliff doesn't add any value. It only causes bad xliff files and lots of errors.

(3) can be solved in 2 ways afaics: (a) Not throw a twig exception when a template could not be rendered because of an exception or (b) avoid logging the twig exception if there is a previous exception.

Now, why the DTD exception is correct: The … entity does not exists in the XML DTD, it only exists in the HTML DTD (source). That's why there is a DTD error.

The fix is available in the XLIFF representation guide:

As a general rule, when extracted to XLIFF, the filter should make all effort to resolve any character entity references to their corresponding Unicode characters. As a last resort, and only if there is no way for the filter to convert the character entity reference, the construct should be treated as an inline code. For example, the following original element:

<p>&aacute;=a-acute, &mychar;=W-circumflex</p>

Should be represented this way:

<source>á=a-acute, W=W-circonflex</source>

Or, at the last resort (this is not the preferred solution) unresolved character entity references could be represented this way:

<source>á=a-acute, <ph id='1'>&amp;mychar;</ph>=W-circonflex</source>

But the <ph> element, just like almost any other inline xliff element, is not supported by xliff atm.

@wouterj thanks for explaining with great detail this problem and their possible solutions. In my personal projects I usually solve this problem using CDATA sections:

<trans-unit id="serializer.summary">
    <source>serializer.summary</source>
    <target><![CDATA[
        Převádí objekty do různých formátů (XML, JSON, Yaml, &hellip;)
        a zpětně z nich je načítá.
    ]]></target>
</trans-unit>

What do you think of this solution?

What do you think of this solution?

It's simple, but I always look at CDATA the same as fixing "header already sent" errors with ob_start. It is possible and it works, but 90% of the time there is a better/easier solution to fix the problem.

What CDATA does is saying to XML: Skip this section and just pass it through. So if you use CDATA a lot, you can almost say that you are no longer parsing the XML file, you are just passing bytes through.

@wouterj But in this case, this is exactly the behavior we expect: the XML parser should not care about the translation itself and what characters are used, this is indeed just a set of bytes for it.

This should be closed. It can't be improved. The only way to improve the experience is by not recommending Xliff anymore...

Closing it as suggested by @wouterj.