Opened 8 years ago
Last modified 7 weeks ago
#38643 accepted enhancement
Show toolbar (admin bar) in the user's locale (language)
Reported by: | swissspidy | Owned by: | pbearne |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | I18N | Keywords: | needs-patch |
Focuses: | Cc: |
Description
After #29783 and #26511 it might make sense to show the toolbar on the front-end in the user's locale, while keeping the rest of the site in the site's locale.
#29783 actually has a proof-of-concept for that. Screenshot: https://twitter.com/swissspidy/status/773571032963751936
Attachments (2)
Change History (27)
#10
@
4 years ago
I refreshed the previous patch against trunk, and it still needs some work.
Of course, it does not include the lazily evaluated translations (#41305).
Also, the toolbar container should have language attributes when the profile language does not match the page (whether that is in the site default or a third language).
This ticket was mentioned in Slack in #core-i18n by sabernhardt. View the logs.
23 months ago
#15
@
11 months ago
- Summary changed from Show toolbar in the user's locale to Show toolbar (admin bar) in the user's locale (language)
I am changing the Summary to make it easier to find this ticket. I believe that this is called Admin bar, so I didn't search for a toolbar
This ticket was mentioned in PR #7077 on WordPress/wordpress-develop by @pbearne.
6 months ago
#16
- Keywords needs-refresh removed
Updated the admin bar styles in WordPress, adding a function to automatically set the text direction based on the user's locale. This helps ensure correct rendering of the admin bar for right-to-left languages. The function also restores the previous locale after rendering the admin bar.
#17
@
6 months ago
- Owner set to pbearne
- Status changed from new to accepted
refreshed
not sure how to test this :-)
@swissspidy commented on PR #7077:
6 months ago
#19
The issue with post type labels being in the wrong locale is still unsolved
This ticket was mentioned in Slack in #core by chaion07. View the logs.
4 months ago
#21
@
4 months ago
- Milestone changed from 6.7 to Future Release
Thanks for moving this ticket forward, but it likely will not be ready for 6.7.
#22
follow-up:
↓ 23
@
7 weeks ago
- Component changed from Toolbar to I18N
- Keywords needs-patch added; has-patch changes-requested removed
#23
in reply to:
↑ 22
@
7 weeks ago
Replying to swissspidy:
I tried to look at this but could not see the issue with the post labels
Can you provide an image of the faulty text?
#24
follow-up:
↓ 25
@
7 weeks ago
It's not a "faulty text". The fundamental problem is that post types are registered in the current locale and then the labels are just translated into the current locale. Switching locales does not have any effect anymore. So even if you show the toolbar in the user's locale (which we had a patch for for 8+ years), the post type labels will always be incorrect, which is very confusing.
There are long prior discussions at #26511 and #38218.
#41305 is probably the only way to truly solve this, which is also mentioned in an earlier comment above. But that has significant drawbacks around backward compatibility.
#25
in reply to:
↑ 24
@
7 weeks ago
Replying to swissspidy:
It's not a "faulty text". The fundamental problem is that post types are registered in the current locale and then the labels are just translated into the current locale. Switching locales does not have any effect anymore. So even if you show the toolbar in the user's locale (which we had a patch for for 8+ years), the post type labels will always be incorrect, which is very confusing.
There are long prior discussions at #26511 and #38218.
#41305 is probably the only way to truly solve this, which is also mentioned in an earlier comment above. But that has significant drawbacks around backward compatibility.
I feel this patch is the best we can do for now and a good step in the right direction.
Can we get this added?
38643.diff should do the trick. Post type labels need to be fixed first though. See discussion at #26511 for this.