admin title does not get translated

And a similar improvement can be made in /wp-admin/customize.php, line:

echo sprintf( __( 'You are customizing %s' ), '<strong class="theme-name site-title">' . get_bloginfo( 'name' ) . '</strong>' );

should be

echo sprintf( __( 'You are customizing %s' ), '<strong class="theme-name site-title">' . get_bloginfo( 'name', 'display' ) . '</strong>' );

Why would you translate the name of your site?

Because people want to. I am not sure, but people do this. SEO is probably one reason. Some people wish to have their translated site to be fully translated, including title.

When they do translate title, they put line like this “[:en]English Title[:de]German Title” etc. Right now, this line is shown as is in <title> on admin pages, while gets translated correctly on site itself. It would be nice to see properly translated <title> on admin pages too.

In any case, the use of the get_bloginfo( 'name' ) at that places is the display, so it would be consistent to fetch ‘display’ value.

Sorry I asked that poorly.

Why do you want to translate it on the BACK end of WP. I can see why you’d want to on the display end, and for that you can just edit your theme.

That particular place is not used for editing, it is used for display only. When it is fetched for editing, it must be in ‘raw’ format, and it is, no problem, but that particular place fetches it to put it into <title> header of the admin page, and then one can see language tags, like “[:en]” etc. in the window tab, which feels like something is broken.

As I said, this is not very important, since it does not affect functionality, it is just not nice and some people might think that something is broken. One would expect to see it in currently chosen admin language, and not all languages in one line, separated by special tags, which looks weird and unexpected. Once again, it does not prevent anyone from doing the work, but it makes you feel like something in the development is left messy and unfinished.

Yes, it might be possible to filter it, and I would not bother WP with that, I simply did not look into filtering yet, since I thought that it would make more sense to make it consistent, and to fetch ‘display’ value, when it is used for display, and ‘raw’ value when raw value is needed. In this place ‘display’ value is meant to be fetched.

/wp-admin/admin-header.php is on the BACK end of WP, though. It’s not something a visitor would see. That’s why I’m trying to understand why it’s necessary to translate.

Yes, visitors do not see it, people who work on the site, do. Also people, who logged on, I am not sure what level of access is needed for that, most probably any access. But in any case, get_bloginfo at both places, which I mentioned, is called for the purpose of display and not editing, so it needs to use ‘display’ mode when fetching a value.

It is the same like, when you switch language at admin page, you get all menus in one language chosen, and not all languages. Same here, that value needs to be shown in currently active admin language. That is achieved, but providing ‘display’ mode for the second argument of get_bloginfo call.

I am sorry, I thought it would be very simple and self-obvious for anyone, once it is pointed out. I did not mean to make so huge discussion about it. Have you looked at the actual code around and how it is used? It may help you to understand that that call is for ‘display’ purpose, but it is done in ‘raw’ mode instead. It is a simple tiny development overlook, as it seems to me.

By changing it, you will surely not break anyone, who has raw and display value the same, which are all single-language sites. Other people who have those values different, probably filtered it out to fix them. I just thought that this issue is so simple that it is best to fix it at the source.

Thank you for your patience with me, I really appreciate your effort.

why it’s necessary to translate

Hi Mika, maybe I have chosen a bad title for the topic? I do not feel that you comprehended the issue. This is not about translation only after all. Are you developer yourselves? Could you pass this topic to the developers? Thanks a lot.

She’s a swell developer and you’ve posted to the right place. No need to pass this on to anyone. ??

What are you attempting to translate in code? The actual name of your site?

Every question I heard so far was not on topic or already answered, including the last one. Maybe my wording is really bad, sorry. Could you just read through this thread, then research how the code works in the places I mentioned, and I expect you to discover it yourselves, why and how.

If you give me a valid reason, which I missed, why those places should use ‘raw’, instead of ‘display’, I will be happy to learn.

What are you attempting to translate in code? The actual name of your site?

That’s what it looks like, Jan.

The code to do it just isn’t in core at the moment, so … you can’t without hacking core which I don’t recommend.

Hi Mika, yes, I understand that the code for translation is not in the core and should not be there by the current design. I only suggest to replace the calls get_bloginfo( 'name', 'raw'[default argument]); with get_bloginfo( 'name', 'display' );, as the value fetched at that place is used for display purpose. That is all. It fits well with WP policies and/or arrangements for back-end design.

The translation, which I want, will happen automatically then within plugins I am using. I tested it before creating this thread, it works perfectly. There is no need for an extra coding to do the translation in the core. I am not asking you to do the translation in the core. I am not asking you to solve any problem. I am offering a fix already found, and very easy to implement, touching two lines of the code only, which were overlooked by the original developer at those places.

I am trying to help and expected simple “thank you” in the response, but I still do not feel that I provided a good enough explanation for you guys to get engaged. You got stuck on the idea that back-end must not provide a translation, which I do not argue with. I am only saying that in those particular places the value brought in by the call of get_bloginfo is meant for display purpose, and that is why get_bloginfo should be called in ‘display’ mode.

I am not sure what else I can say to make you go to the code and to see it by yourselves. I hope you will eventually understand, if you take enough time to investigate how the code works in the places mentioned. Thank you very much for your patience.

While you guys research it, I thought, the following addition may help. I realized, that I should not have used word ‘translation’ in the subject, since this is secondary to the issue, although a problem related to a translation made me discover this place.

Please, forget “translation” for a moment, just look through the code around the places mentioned and tell me why ‘raw’ argument is better than ‘display’. What would get broken, if ‘raw’ is replaced with ‘display’? It is by WP design, if a variable is fetched for the purpose of display, then call to get_bloginfo should use ‘display’ argument, is not it? Are not those places for display?