Skip to content
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

Rephrase sentences to exclude mention of a post type #16773

Open
OlaIola opened this issue Mar 14, 2021 · 5 comments
Open

Rephrase sentences to exclude mention of a post type #16773

OlaIola opened this issue Mar 14, 2021 · 5 comments

Comments

@OlaIola
Copy link

OlaIola commented Mar 14, 2021

Russian has different ends of words in different cases and translates phrases this way looks unnatural:
"Allow search engines to show this %s in search results?" - here we should have an accusative form
"Should search engines follow links on this %1$s?" - here we should have a prepositional form

2021-03-11_08-21-30

I don't think it's possible to make it fit easily, and I propose to exclude mentioning the post type from these phrases.

@Djennez
Copy link
Member

Djennez commented Mar 17, 2021

@OlaIola I don't think this is really a plugin bug. Do you think this can be fixed by changing the translation? If so, can you submit a suggestion at the translations page?

@OlaIola
Copy link
Author

OlaIola commented Mar 24, 2021

I don't think it can be fixed by translation because you cannot chuck out %s the string will become fuzzy. Passive voice can be used to make word forms look right, but it isn't a good practice and the second sentence will look ugly and vague in Russian.

@Djennez
Copy link
Member

Djennez commented Mar 24, 2021

Ah ok, well I'll have to take your word for it since I don't speak / read Russian 😄

@tobifjellner
Copy link

We have part of the same thing in Swedish. When (for instance) the name of a post type is injected into a string, I don't know which grammatical gender I should use for it. Sometimes I overcome this by adding the extra word "post type" into my translation.
In the string Olga refers above, there's one more problem: If you try to include the post type directly in the sentence, then it should in many languages start with lower-case instead.
For posts and pages, the best fix is to NOT use placeholders, but have two separate strings in the code:

  • Allow search engines to show this page in search results. AND
  • Allow search engines to show this post in search results.
    For other post types, you could use something slightly heavier:
  • Allow search engines to show this object (post type: %s) in search results.

@SergeyBiryukov
Copy link
Member

SergeyBiryukov commented Mar 24, 2021

As noted above, just inserting a post type name into a generic string like Should search engines follow links on this %1$s? is not translatable, that is why WordPress itself uses an array of various post type labels.

A general best practice in WordPress is to avoid post type and taxonomy names in generic strings due to i18n concerns and structural differences in languages. See the previous discussions for reference:

To clarify a bit more, while both the post type name and the string itself can be translatable, this or any other generic string like that is not correctly translatable. It does not account for grammatical gender or declensions in other languages, so no matter how you translate it, the result is still incorrect.

For example, in Russian, "Post" is feminine and "Product" is masculine, so "on this post" and "on this product" would require a different translation and there is simply no way to translate on this %s to account for both. We also don't use capital letters for multiple words in a row, so "on this Post" or "on this Product" is not quite correct, it should be "on this post" or "on this product".

That is the case for many other languages too, and is the reason why WordPress core does not use generic strings for post type or taxonomy names, and offers an array of labels to be used instead.

Searching for /* Translators: %s translates to the Post Label in singular form */ or similar comments in the plugin code, I've found several affected strings in JS files:

  • __( "Allow search engines to show this %s in search results?", "wordpress-seo" )
  • __( "Should search engines follow links on this %s", "wordpress-seo" )
  • __( "Make sure to save your %s for changes to take effect", "wordpress-seo" )
  • __( "Return to your %s", "wordpress-seo" )
  • __( "%s (current default for %s)", "wordpress-seo" )
  • __( "Default for %1$s (%2$s)", "wordpress-seo" )
  • __( "You can change the default type for %1$s in your %2$sSearch Appearance Settings%3$s.", "wordpress-seo" )
  • __( "Unfortunately we cannot save changes to your SEO settings while you are working on a draft of an already-published %1$s. " + "If you want to save your SEO changes, make sure to click 'Update', " + "or wait to make your SEO changes until you are ready to update the %1$s.", "wordpress-seo" )

Searching for /* translators: %s expands to the post type name. */, or similar comments, I've found some more in PHP files:

  • __( 'Allow search engines to show this %s in search results?', 'wordpress-seo' )
  • __( 'Default for %2$s, currently: %1$s', 'wordpress-seo' )
  • __( 'Should search engines follow links on this %1$s?', 'wordpress-seo' )
  • __( 'Settings for single %s URLs', 'wordpress-seo' )
  • __( 'Settings for %s archive', 'wordpress-seo' )
  • __( 'the archive for %s', 'wordpress-seo' )
  • __( 'Breadcrumb settings for %s archive', 'wordpress-seo' )

There might be more if some other strings don't have that comment. These will all need to be changed to have a different default string for hierarchical and non-hierarchical post types, similar to how WordPress core handles it, see get_post_type_labels().

  • For non-hierarchical post types:
    __( "Allow search engines to show this post in search results?", "wordpress-seo" )
  • For hierarchical post types:
    __( "Allow search engines to show this page in search results?", "wordpress-seo" )

For any custom post types, there should be a filter so that developers could change the strings based on the specific post type. Trying to account for any random post type in the translation is not feasible, for the reasons described above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants