Post Title: Displays the post type name as preview in the editor

[gigitux]

What problem does this address?

Currently, in the editor, the preview of the Post Title is hard coded and it is Post Title. Instead of hardcoding Post Title, rendering the post type name in the preview would improve the user experience.

For instance, in the image below, I'm editing the Single Template for the post type Movie. The Post Title Block should show Movie Title instead of Post Title.

[draganescu]

This is a cool idea, let see if from a design perspective we're not missing something 👏🏻

[ntsekouras]

I guess we'd need either a new post type label for this use case or resort to something like Title of post type: Movie for i18n reasons.

[gigitux]

I guess we'd need either a new post type label for this use case or resort to something like Title of post type: Movie for i18n reasons.

Is there a particular reason? From what I know, the translators can move the position of the variable. For example, in English would be: %s Title, and in Italian could be Titolo del %s.

[ntsekouras]

From what I know, the translators can move the position of the variable

I'm not sure about this, but in similar past situations, the suggestion was that. --cc @mcsf

[mcsf]

Is there a particular reason? From what I know, the translators can move the position of the variable. For example, in English would be: %s Title, and in Italian could be Titolo del %s.

If your Movie post type is translated to Italian as Film, that's fine. If it's translated as Pellicola, your string is now grammatically wrong (Titolo del pellicola) [for other readers: the former is masculine and the latter is feminine, so the correct rendering would have been Titolo della pellicola]. With this very simple example you can see how string interpolation in i18n almost always fails in many languages. In Italian you'll often run into gender agreement, but also person agreement, but other languages will have kinds of grammatical agreement that may seem wild to you (e.g. case, alliteration).

So what we do is avoid string interpolation, even if it works in English. Sure, the translator could always "fix" the string for their locale (e.g. %s title -> %s — titolo to bypass gender agreement), but that puts the onus on translators to catch all the ways a string interpolation may fail, and it encourages developers to make too many assumptions.

This is why @ntsekouras was saying that, other than introducing a new label for all post types to use, the only way to have specific strings that don't break in other locales is to write robotic-sounding strings like Title of post type: %s. Which feels cheap.

[gigitux]

If your Movie post type is translated to Italian as Film, that's fine. If it's translated as Pellicola, your string is now grammatically wrong (Titolo del pellicola) [for other readers: the former is masculine and the latter is feminine, so the correct rendering would have been Titolo della pellicola]. With this very simple example you can see how string interpolation in i18n almost always fails in many languages. In Italian you'll often run into gender agreement, but also person agreement, but other languages will have kinds of grammatical agreement that may seem wild to you (e.g. case, alliteration).

Thanks for your explanation!

This is why @ntsekouras was saying that, other than introducing a new label for all post types to use, the only way to have specific strings that don't break in other locales is to write robotic-sounding strings like Title of post type: %s. Which feels cheap.

I'm not sure that I understand what you suggest. If I understood well, Did you suggest setting a new label on the post type level that will be used by the post title block? If yes, we have other blocks that are affected by the same issue and I'm not sure that defining a specific label for each core/block that requires an improved preview is a good approach. (maybe I didn't get your suggestion)

[mcsf]

I'm not sure that I understand what you suggest. If I understood well, Did you suggest setting a new label on the post type level that will be used by the post title block? If yes, we have other blocks that are affected by the same issue and I'm not sure that defining a specific label for each core/block that requires an improved preview is a good approach. (maybe I didn't get your suggestion)

I wasn't so much suggesting any particular path, but rather explaining how i18n is surprisingly difficult. One could say that I was just raising problems and not helping solve them. :)

I had a look at the tickets linked under #49108. If I understood correctly, we have:

1. Post Title: Displays the post type name as preview in the editor #48963 (this) and Comments Title: Displays the post type name as preview in the editor #50169, which both hinge on the (un)availability of a label like "Movie title"
2. Post Excerpt: Displays the post type name as preview in the editor #48964, which is about clarifying for users the role of the Post Excerpt block by presenting a sentence like "[this block] will display the excerpt from single movies|posts|etc."

For 1), you could propose a new post type label (something like postType.labels.title = 'Movie title'), but realistically I think a simpler and more sustainable path would be to manually accommodate some core types and fall back to a generic label — for example:

switch ( postType ) {
  case 'post':
    label = __( 'Post title' );
    break;
  case 'page':
    label = __( 'Page title' );
    break;
  case 'wp_template':
    label = __( 'Template title' );
    break;
  case 'wp_template_part':
    label = __( 'Template part title' );
    break;
  default:
    label: __( 'Title' );
}

For 2), there's really no acceptable way to assemble those UI strings without breaking things in other locales. I can give you the example of Finnish, which is always a fun case because of how inflected this language is. Despite my sympathy for the language, I don't speak it, so we'll have to resort to some reference material. Today, instead of looking at declension tables online, I just asked GPT to compare some strings. Let's assume it did a passable translation job and compare:

• English: It will display excerpts from movies.
  • Finnish: Se näyttää elokuvista otteita.
• English: Movies.
  • Finnish: Elokuvat.
• English: This theatre has shown several movies.
  • Finnish: Tämä teatteri on näyttänyt useita elokuvia.

Notice how the translated form is different in each sentence, even though it always corresponds to the same English word. That's the first red flag for string interpolation.

Another way in which this won't work is the same kind of gender agreement issue that I explained earlier in this thread: how do you stitch together something like single [movies]? Looking once again at Romance languages, you expect adjectives to reflect the gender of their noun — unless it happens to be a uniform adjective, but that's the exception.

So... in order to move forward, the takeaway is: this is tricky, but I recommend finding simpler ways to phrase user strings so that we don't feel the need to interpolate things: "This is the Post Excerpt block. It will display an excerpt of the corresponding content", or something more graceful.

[gigitux]

@mcsf, thanks for your great explanation! i18n is very complex 🫣

@carolinan suggested a very easy solution: rename the name of the blocks and make the labels more generic (no interpolations!)

I updated both PRs. Happy to receive feedback!