-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Translation] Plural handling in .po files completely broken since 4.3.3 #34467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
/cc @Stadly in case you want to have a look. |
I'm not entirely convinced that this is a bug. At least the old functionality was not correct, even though it seemed to work correctly in your case. I'll try to come back to it during the weekend. |
From https://symfony.com/doc/current/components/translation/usage.html:
The key point here is that the message is used as the
Further down on the page, there is an example with plurals (using the old
Either, you have to include both the singular and plural in the message: echo $translate->trans('There is currently 1 bug|There are currently %count% bugs', ['%count%' => 1]) . "\n";
echo $translate->trans('There is currently 1 bug|There are currently %count% bugs', ['%count%' => 3]) . "\n"; Or you have to use a message keyword, and supply translation files for both English and German: echo $translate->trans('bug.count', ['%count%' => 1]) . "\n";
echo $translate->trans('bug.count', ['%count%' => 3]) . "\n"; This is just how the Symfony Translation Component is designed to work. |
@Stadly, what do the PO file look like for this example? I have separate PO files for all languages and don't see how it would work
|
EditWhen using
Original comment (for reference)
|
Or make it explicit that the message is pluralizable in the message keyword:
This would be the PO file:
|
@Stadly I'm quite uncomforable with the idea of leaking internal implementation details of symfony translate into my frontend code like that. The way that symfony translate creates internal representations of the data should be transparent to the calling code, otherwise you just break encapsulation and create a massive amount of work for every user of the framework if the internal details change |
@BjornTwachtmann I completely agree. The issue is not really with Symfony's internal representation of data, but with converting between the plural formats used by Symfony and PO. Most translation formats don't have native support for pluralization, and the message id simply maps to a message string in Symfony's pluralization format, such as
PO, however, has native support for pluralization. Let's consider this file: $translate->trans('bug.count', ['%count%' => 1]);
$translate->trans('bug.count.singular|bug.count.plural', ['%count%' => 2])
$translate->trans('There is currently 1 bug|There are currently %count% bugs', ['%count%' => 3]); If we don't want to utilize PO's native support for pluralization, we can use such a PO file (this is comparable to how most other translation formats work):
In #31266, support for PO's native pluralization format was implemented. So now we also have the option to use such a PO file:
So all three message id approaches work in both PO translation formats and all other formats. By using |
This issue can probably be closed now. |
Symfony version(s) affected: >=4.3.3
Description
When attempting to translate entries from .po files that are in plural form, translation fails and the original input string (with substitutions) is returned rather than the translated form.
How to reproduce
The following script and .po file illustrate the problem. They work correctly in symfony/translate 4.3.2 and are broken in >=4.3.3
test.po
test.php
Possible Solution
This bug appears to have been introduced in #31266 . Reverting that code restores the original behaviour. Honestly I'm very confused as to how this was meant to work. Symfony, post this change, appears to be expecting you to ask for translations of plural forms as follows:
$translate->trans('There is currently 1 bug|There are currently %count% bugs', ['%count%' => 3])
. This is clearly unacceptable as it a) breaks existing behaviour (which is also standard behaviour across any app that uses .po files) in a patch release, and b) requires the calling code to know details of Symfony's internal representation of a translation.The text was updated successfully, but these errors were encountered: