Opened 7 years ago
Last modified 7 months ago
#37287 reopened defect (bug)
wp_print_admin_notice_templates() does not use _n*() for plural forms
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 4.6 |
Component: | I18N | Keywords: | needs-patch |
Focuses: | javascript, administration | Cc: |
Description
Function wp_print_admin_notice_templates() (https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/update.php#L615) does not properly use _n() and related functions for plural forms of its strings. It just makes a simple if (count ===1) check and uses two different strings - one for singular, one for plural form.
This presents a problem when translating into languages that have more than one plural form, or more complicated rules for singular form usage. For example, in Lithuanian we also use singular form for 21, 1241 and any other number that ends with 1 (except for 11). And we have two plural forms - one for numbers ending with a zero, another for everything else. In current situation we can not have a proper translation here.
Attachments (2)
Change History (22)
This ticket was mentioned in Slack in #feature-shinyupdates by arunas. View the logs.
7 years ago
#3
follow-up:
↓ 5
@
7 years ago
Noticed the same when translating yesterday. Yes, it depends on #20491 to be implemented properly (we can't just use _n()
here, as it's a JS template).
For now, I would use some kind of a workaround in translation, e.g. "Plugins (%s) successfully updated".
#5
in reply to:
↑ 3
@
7 years ago
Replying to SergeyBiryukov:
Noticed the same when translating yesterday. Yes, it depends on #20491 to be implemented properly (we can't just use
_n()
here, as it's a JS template).
For now, I would use some kind of a workaround in translation, e.g. "Plugins (%s) successfully updated".
Well, we could hold of on introducing faulty logic into the core and use generic strings right there.
But I guess shiny updates have to be, well, shiny. At least in English :)
I haven't looked into where data.successes comes from, but if it originates in PHP, maybe we could pass a pluralized string to it readily instead of having that logic in JavasScript at all? OK, I see we can't do that here.
This ticket was mentioned in Slack in #polyglots by pokeraitis. View the logs.
7 years ago
This ticket was mentioned in PR #2778 on WordPress/wordpress-develop by daledupreez.
12 months ago
#9
- Keywords has-patch added; needs-patch removed
This PR updates the template used for bulk updates to use client-side localisation via wp.i18n._n()
to handle plurals correctly. I do have some concerns, though:
- Will these translations be correctly picked up now that they're in server code that is using the client-side functions?
- What is the correct way to add translation comments for the code approach above?
Trac ticket: https://core.trac.wordpress.org/ticket/37287
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
8 months ago
#12
@
8 months ago
- Keywords dev-feedback added
The patch works fine on my side.
pinging @SergeyBiryukov for additional review, but I think we're good to go with PR2778.
#13
@
8 months ago
- Keywords commit added; dev-feedback removed
- Owner set to audrasjb
- Status changed from new to accepted
Self assigning for commit
.
#15
@
8 months ago
- Keywords revert added; commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening and suggesting revert of [54469] for now since there's currently no support for parsing JS i18n functions in PHP files which means the strings won't be translatable.
#16
@
8 months ago
Oh, alright, I'm reverting it right now.
I'll move it to Future Release after it's reverted. Thanks.
#19
@
7 months ago
Thanks for flagging that gap, @ocean90! This was one of my original concerns with my PR.
Do you know if we have an issue for adding that support to our translation tools? I'd like to make sure we flag this issue as blocked by that support (or possibly a motivator for adding it!).
#20
@
7 months ago
- Keywords needs-patch added; has-patch removed
@daledupreez I think the proper solution would be to move this somehow into the existing JavaScript file instead of having this template in PHP.
OK, as I understand, this will not get fixed until #20491 gets fixed. So not in time for 4.6 or anything like it. Just use generic strings.