[Translation] Allow specification of translation key in addition to content string in Twig templates #41797
Description
Description
The current Symfony Best Practices for Internationalisation recommend using translation keys instead of content strings, which has unquestionable advantages. However, using only translation keys when creating new templates is currently rather non-verbose and slow, since the website content must then be added as translation in a second step and cannot be seen (as context) inside the template.
This is why I propose a new attribute/parameter to the existing Twig tags/filters/functions (t/trans) for optionally specifying a translation key next to the (initial) target value. Template writers can then easily provide an initial value and context for the default locale, while keeping the benefits of translation keys, such as changing the text of the default locale later (inside the translation files) without having to update all other locales.
I have implemented a working example for the {% trans %}-tag using the following syntax:
{% trans as 'translation.key' %}Proposed initial content string{% endtrans %}
I did not create a pull request yet, since the functionality is not complete nor fully tested or documented and I wanted to request comments first.
Example
- Input
demo.html.twig:
{% trans_default_domain 'demo' %}
Current behaviour, using translation keys: non-verbose and slow to create:
{% trans %}test.message.as.key.without.default.text{% endtrans %}
Current behaviour, using content strings: verbosity in templates and fast creation, but several disadvantages:
{% trans %}Test message without explicit id, but with default text{% endtrans %}
Proposed new behaviour: Explicit translation key with content string:
{% trans as 'test.message.with.key.and.text' %}Test message with explicit id and default text{% endtrans %}
- Resulting
demo.en.xlfafter runningphp bin/console translation:update --force --domain=demo en(when using my sample implementation):
[...]
<trans-unit id="g7UN0Df" resname="test.message.as.key.without.default.text">
<source>test.message.as.key.without.default.text</source>
<target>__test.message.as.key.without.default.text</target>
</trans-unit>
<trans-unit id="d5CC0j2" resname="Test message without explicit id, but with default text">
<source>Test message without explicit id, but with default text</source>
<target>__Test message without explicit id, but with default text</target>
</trans-unit>
<trans-unit id="SCGnBjM" resname="test.message.with.key.and.text">
<source>test.message.with.key.and.text</source>
<target>__Test message with explicit id and default text</target>
</trans-unit>
[...]
Exporting the translation unit correctly to XLIFF with the translation key as resname, the content string as unprefixed <source> and as prefixed (if not default locale) or unprefixed (if default locale) <target> would, however, require further modification and can be subject of another feature request (similar issue: #33041). The optimal resulting XLIFF files would, in my opinion, look like this:
- Optimal
demo.en.xlf(note the<source>and the unprefixed<target>):
[...]
<trans-unit id="SCGnBjM" resname="test.message.with.key.and.text">
<source>Test message with explicit id and default text</source>
<target>Test message with explicit id and default text</target>
</trans-unit>
[...]
- Optimal
demo.fr.xlf(note the prefixed<target>):
[...]
<trans-unit id="SCGnBjM" resname="test.message.with.key.and.text">
<source>Test message with explicit id and default text</source>
<target>__Test message with explicit id and default text</target>
</trans-unit>
[...]