Not modify, but you could use it as a guide towards adding another rewrite rule. We cannot modify this code because rewrite rules are persistent, they are only occasionally generated. This means you cannot add conditional logic like “if the locale is “de_DE” then do X, else do Y”. Instead you need to address all possibilities separately.
Before doing that, are you sure you only need a rewrite rule for this one page (whose path is “/ci/1/” or “/ci1”)? Wouldn’t there be other pages to rewrite?
Or is it you only want rewrite rules for German (and later English) slugs? And these are totally unrelated to this “/ci1” page? If so, rewrite rules are not what you need to add or modify. Instead you need to modify the query vars to query for German slugs as post meta values instead of the usual post name values.
Through the “pre_get_posts” action, if the locale is “de_DE”, get the query var value of either “name” or “pagename” and use it to set the “meta_value” query var, along with setting “meta_key” to the key name you use to store German post slugs. Then unset the initial “name” or “pagename” query var.
Once again, if your key names follow a consistent pattern which includes the 2 character language code, you can manage several languages all with the same code. Similar to:
$the_query->set('meta_key', 'post_slug_'. $lang );
I would like to use a single scheme for all languages. The general rule is this: when the subdomain page URL begins with a prefix indicating a language (e.g. “de.” for German, “en.” for English, “fr.” for French), then the page slug must match the title of the page in that specific language. The title field in each language always follows the same pattern: “title_de”, “title_en”, “title_fr”, etc.
You don’t need any other rewrite rules to do this, you instead need to alter the query through the “pre_get_posts” action. In the added callback, get the locale. If it’s “it_IT”, do nothing. Otherwise extract the 2 character language code from locale and assign it to $lang.
Then get the requested slug from the “name” query var. Use the value to set the “meta_value” query var. Unset the “name” query var. Also set the “meta_key” query var to 'title_'.$lang.
Thus a post will be found whose translated slug in post meta matches the requested slug.
What you will need added rewrite rules for is if you want to translate taxonomy archive URLs like /tipologia/appartamento/ to /tipologie/wohnung/
So I could transform what I already have simply replacing a filter by an action?
add_filter('the_title', function( $title, $post_id ) {
$locale = get_locale();
if ('de_DE' == $locale ) {
$title_de = get_post_meta( $post_id, 'title_de', true );
if ( ! empty( $title_de )) {
return $title_de;
} else {
return $title;
}
} else {
return $title;
}
}, 10, 2 );
No, it will not be that easy. In “pre_get_posts” you are changing the criteria used to make a query for the correct post. Start with one of the examples n the doc page. Much will change, but it’ll give you the basic structure.
In the if() checks, ! is_admin() && $query->is_main_query() is good. Also verify the locale is not “it_IT”. Then proceed as I described earlier.
Where I said you should unset a query var, you would actually set an empty string. For example $query->set( 'name', '' );
function search_filter($query) {
if ( ! is_admin() && $query->is_main_query() ) {
if ( $query->is_search ) {
$query->set( 'post_type', 'post' );
}
}
}
add_action( 'pre_get_posts', 'search_filter' );
I just use one post_type= post, so $query->set( 'post_type', 'post' ); should be cancelled, or maybe I can keep it just in case
I’m not sure $query->is_search will be true for your particular search. Usually is_search is only true when the “s” query var is set. While you’re doing a search, it’s a custom search, not a default WP search.
Instead of checking if it’s a search, I would verify the locale is not “it_IT”. Also verify if is_singular is true.
You don’t really need to set “post_type”, the default is “post” anyway. But you do need to get the “name” query var, set “meta_key” and “meta_value” query vars, then finally set “name” to an empty string.
like this maybe
function search_filter($query) {
if ( ! is_admin() && $query->is_main_query() ) {
if ( $query->is_singular ) {
if ( $locale (! it_IT) )
$query->set( 'post_type', 'post' );
}
}
}
add_action( 'pre_get_posts', 'search_filter' );
Close. $locale is currently undefined, you need to get_locale(). And to check something is not equal we use != operator. Like so:
if ('it_IT' != get_locale() ) {
//set and unset query vars here
}
Within this conditional is where you would do:
get the requested slug from the “name” query var. Use the value to set the “meta_value” query var. Unset the “name” query var. Also set the “meta_key” query var to ‘title_’.$lang.
function search_filter($query) {
if ( ! is_admin() && $query->is_main_query() ) {
if ( $query->is_singular ) {
if ('it_IT' != get_locale() ) {
//set and unset query vars here
$query->set( 'post_type', 'post' );
}
}
}
add_action( 'pre_get_posts', 'search_filter' );
How can I target the title in the URL, in order to filter it by locale?
Similar to other translation code, extract out the 2 char language code from the locale and assign it to $lang. But now you will use it to set the “meta_key” query var. Like this:
$query->set('meta_key', 'title_'.$lang );
I did
// FILTRO PER RISCRIVERE TITOLO NELL'URL IN TUTTE LE LINGUE
function search_filter($query) {
if ( ! is_admin() && $query->is_main_query() ) {
if ( $query->is_singular ) {
if ('it_IT' != get_locale() ) {
//set and unset query vars here
$query->set('meta_key', 'title_'.$lang );
}
}
}
}
add_action( 'pre_get_posts', 'search_filter' );
but when I get the german version of the page, first of all the title in the URL keeps on being in italian and besides the page has no content, I get an error message, “page not found”
You need to also set the “meta_value” query var to whatever the requested slug is from the “name” query var. Then set “name” to an empty string. That should get the right post, but you might still see the URL change to Italian. In addition to the “pre_get_posts” action, we may need to use the “redirect_canonical” filter to prevent the URL change.
Let’s get this query action working correctly first. If the URL change remains an issue we can address that later.
