switching from an inner page in italian into an inner page into i.e english

but if I remove this code all the content of the site is not translated

That code is fine, while it’s locale related, it has nothing to do with the language switcher menu items. You should be looking for something that involves both locale and menu item URLs, but not menu item titles.

Another possibility that explains your inability to properly switch languages would be if some pages are cached and don’t reflect the influence of the most recent code. Try flushing your browser’s cache.

I found the solution but it is not related to a hidden code. I used ITALIAN as the top position, then DEUTSCH in 1st place in the submenus and ENGLISH in 2nd place in the submenus, regardless of the language version, so it works. In practice I did not use the meta fields that I used to translate the terms of the menu, and so these three words are always seen in the same order in the 3 language versions

Actually, I would like a German to see “DEUTSCH” in the top position of the menu, not “ITALIANO”. I can’t say at 100% that there is not a code that interferes, but empirically, doing as I did now, the problem doesn’t exist. Anyway Is there a way to include the meta fields in the function and not just the menu titles?

Now I’m trying the exceptions. The code

f ( in_array( $_SERVER['REQUEST_URI'], ['/contatti/','/contact/',] )) $item_post->url = get_site_url( null, '/kontakt/');

should replace

$item_post->url = get_site_url( null, $_SERVER['REQUEST_URI']); 

?

Is the one above for the German version, i.e. when there is DEUTSCH?

doing as I did now, the problem doesn’t exist.

Great! Whatever gets it done ??

I would like a German to see “DEUTSCH” in the top position of the menu

There are two or three possible approaches. I’m not sure which is better.

One is to not use the admin area menu edit screen for language switcher items. Instead insert your own menu item structure at the end of what wp_nav_menu() outputs. It would be styled to look like the wp_nav_menu() items, but in fact it would be a separate menu. The language switcher menu could be generated 100% from your own code which creates the right structure based on locale so the current locale’s menu item is always on top.

Or, two, you could still use the admin area menu edit screen to create 3 separate language switcher menus and your template code would output the correct one based on locale.

Third option is to use the ‘wp_nav_menu_objects’ filter to alter the menu_order and menu_item_parent properties of appropriate items so the current locale’s item is always on top. It might also be necessary to re-order the passed array so that the element order matches the menu_order values. I’ve never used this approach, but I’m fairly certain it would work.

Is the one above for the German version

Yes. Because of get_site_url( null, '/kontakt/'), it goes with the DEUTSCH menu item. These exceptions are in addition to, they do not replace $item_post->url = get_site_url( null, $_SERVER['REQUEST_URI']); Exceptions must go after this line.

There must be something wrong with this code: https://pastebin.com/T4fnPB0E In any case, even if it worked, I need the old filters https://pastebin.com/bBjZAntv because, unlike ITALIAN DEUTSCH and ENGLISH, the other menu items such as “contatti” are translated using meta fields (‘link_tedesco for german and ‘link_inglese for english). I think there is no conflict in using the new code for ITALIAN DEUTSCH and ENGLISH and the old code for the other items at the same time,  on the condition that the code that establishes the exceptions works well, in my opinion this code it is not currently working

ADDED: ps: maybe everything is working fine and the problem is that I just put the exceptions for “contatti”, I have to add exceptions for the other words

I am also preparing to migrate the code to sacconicase.com and de.sacconicase.com, en.sacconicase.com how can I replace elements in str_replace?

I did an experiment and replaced ://en.test with ://en.test.sacconicase , and so on., but it didn’t work…

• This reply was modified 2 weeks, 4 days ago by sacconi.
• This reply was modified 2 weeks, 4 days ago by sacconi.

Ok, it seems allright now, I’m just curious to now if it’s by chance ot also on theoretical basis. Now I just need to change and adapt str_replace for sacconicase.com as above described

the best would be having the same str_replace both for test.sacconicase.com and sacconicase.com

You can manage all possible variants of search and replace by passing arrays to str_replace(). Example for switching to German:

$find   =  ['://test.sac'   ,'://sac'    , '://en.test.sac' ,'://en.sac',];
$replace = ['://de.test.sac', '://de.sac', '://de.test.sac' , '://de.sac',];
$item_post->url = str_replace( $find, $replace, $item_post->url );

this seems to work, is it correct? https://pastebin.com/j7QUAs5d

Yes, looks good!

I have a question, if I wanted to replace the title in the URL in the german end the english versions using the german and the english titles, there is something of the above code that I can keep? Maybe just putting the correct title in the replace funcion ? But if the code is not locale-based I probably have to change everything…My question is related also to the importance of having an optimized SEO for the foreigner versions of the site

• This reply was modified 1 week, 4 days ago by sacconi.

“title in the URL” — Do you mean the post’s slug? For example forte-dei-marmi-appartamento-in-villa-per-6-persone-con-giardino would become forte-dei Marmi-apartment-in-villa-for-6 people-with-garden. Would such an URL lead to the same single post page or an entirely different post page? WP would assume such an URL would lead to a completely separate page. If it’s indeed a separate page, what you need to do is to modify the home page and other archive queries to query for the correct language versions. The URLs would take care of themselves.

If the English URL should instead lead to the same Italian page, except now translated, you could use the “post_link” filter to alter the URL. You can use similar logic for str_replace(), but it’d be in a different callback function, one that is locale based. But instead of using str_replace() for the slug, you’re probably better off reconstructing the the entire URL, for example:

$slug = get_post_meta( $post->ID, "post_slug_$lang", true );
$link = site_url("/$slug/");
// use similar str_replace() logic here for the language subdomain

This is only a code fragment to illustrate a point, it’s not functional code on its own. The str_replace() logic is simpler here because you know that $link will always be the Italian version, it’ll never have the “de.” or “en.” subdomains to start with.

Yes, I meant the ?the post’s slug and URL leads to the same single post page but currently I dont have a post_slug_$lang field somewhere (yet), I have a field for the title and use title_$lang. But this new code will replace the old one in all its parts?

I don’t think you have anything hooked to the “post_link” filter yet, so there’s nothing to replace? AFAIK this would be mostly new code, though you could likely borrow certain snippets from elsewhere. You should have meta fields for translated slugs, but it’d be possible to auto-populate the fields for a new post based on translated title input. For de. and en. subdomains you’d need to alter the queries to find the slug in post meta instead of the usual post name. This can be done through the “pre_get_posts” action hook.

I dont have a “post_link” filter yet, I currently have 2 custom meta fields for the titles in german and in english: “title_de” and “title_en”…