You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 5, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 5, 2025. It is now read-only.
Splitting up of _s_posted_on should be reverted #1256
The current split as has been merged is a deterioration from a localization point of view as the sentence structure is now broken up in two methods and two individually translatable phrases which together form a sentence with the sentence order presuming English / left-to-right sentence structure.
I proposed the original idea. I believe we can address both. But Posted On is a Date function and Posted By is an Authorship function. They should be separate in that regard.
@yoavf I'd appreciate your expertise here, for ways to improve localization of the post title and byline, if there's something we can do in its current form (split into two functions) or if it's best to revert. Thank you!
From a l10n pov, I think that the current version is slightly better than what we had before, but both are actually quite bad.
The best solution would simply be a single string that includes both parts:
Something like __( 'Posted on %1$s by %2$s' ) with %1$s and %1$2 being the localized date and the user link, respectively.
The best solution would simply be a single string that includes both parts:
Something like __( 'Posted on %1$s by %2$s' ) with %1$s and %1$2 being the localized date and the user link, respectively.
I experimented with this, but using a simplified string creates a new issue; the lack of wrappers around the post date and author, allowing us to style these pieces and their surrounding text with CSS.
Should we consider remove the surrounding text altogether? Displaying just the date/time and author separately with a separator, like:
March 3, 2018 | Author Name
If not, it seems like the current solution is a slight improvement, in any case, and should stay.
Reacted by Ulrich Pogson, Philip Arthur Moore and Chris Runnells
I experimented with this, but using a simplified string creates a new issue; the lack of wrappers around the post date and author, allowing us to style these pieces and their surrounding text with CSS.
We can still do this with one function. See #1282 for an untested POC.
Activity
dshanske commentedon Jan 29, 2018
I proposed the original idea. I believe we can address both. But Posted On is a Date function and Posted By is an Authorship function. They should be separate in that regard.
Can you propose a solution that addresses both?
jrfnl commentedon Jan 29, 2018
Sorry, busy with other things at the moment. I'll leave finding a solution for this up to others for now.
dshanske commentedon Jan 29, 2018
Understood.
laurelfulford commentedon Feb 26, 2018
Thanks for creating this issue, @jrfnl!
@yoavf I'd appreciate your expertise here, for ways to improve localization of the post title and byline, if there's something we can do in its current form (split into two functions) or if it's best to revert. Thank you!
yoavf commentedon Mar 6, 2018
From a l10n pov, I think that the current version is slightly better than what we had before, but both are actually quite bad.
The best solution would simply be a single string that includes both parts:
Something like
__( 'Posted on %1$s by %2$s' )with%1$sand%1$2being the localized date and the user link, respectively.sixhours commentedon Mar 8, 2018
I experimented with this, but using a simplified string creates a new issue; the lack of wrappers around the post date and author, allowing us to style these pieces and their surrounding text with CSS.
Should we consider remove the surrounding text altogether? Displaying just the date/time and author separately with a separator, like:
March 3, 2018 | Author NameIf not, it seems like the current solution is a slight improvement, in any case, and should stay.
philiparthurmoore commentedon Apr 3, 2018
Agree with @sixhours here on both of her points.
yoavf commentedon Apr 8, 2018
We can still do this with one function. See #1282 for an untested POC.
grappler commentedon May 13, 2018
I think we need to think outside the box and try something new. Here are a few screenshots from a few blogs.
I am not very keen on adding HTML to the translations strings as suggested in #1282.