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
Fix plural messages not falling back to key. #10911
Conversation
Plural messages without a translated value did not correctly fallback to the message key as singular messages do. This caused undesirable behavior when working with plural messages. I've shifted the plural form resolution into the Translator. Now that we have a custom translator class this logic is better suited here instead of having duplicate logic in each message formatter. Interestingly our formatters had divergent logic for handling plurals which could cause some tedious to fix issues for app developers. I've not unset the `_singular` key in the Translator as userland formatters could be relying on those keys being passed in. Refs #10900
Codecov Report
@@ Coverage Diff @@
## master #10911 +/- ##
============================================
- Coverage 94.94% 94.63% -0.31%
+ Complexity 12138 12130 -8
============================================
Files 422 422
Lines 30170 31107 +937
============================================
+ Hits 28645 29439 +794
- Misses 1525 1668 +143
Continue to review full report at Codecov.
|
src/I18n/Translator.php
Outdated
return $key; | ||
} | ||
if (is_string($message['_context'][$context]) && | ||
strlen($message['_context'][$context]) === 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be written as
if ($message['_context'][$context] === '')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
Plural messages without a translated value did not correctly fallback to the message key as singular messages do. This caused undesirable behavior when working with plural messages.
I've shifted the plural form resolution into the Translator. Now that we have a custom translator class this logic is better suited here instead of having duplicate logic in each message formatter. Interestingly our formatters had divergent logic for handling plurals which could cause some tedious to fix issues for app developers.
I've not unset the
_singular
key in the Translator as userland formatters could be relying on those keys being passed in.Refs #10900