Erwartete WPML-Verhaltensweisen, die wie Probleme aussehen können

Einige Dinge funktionieren auf einer mehrsprachigen Website absichtlich anders: eine WordPress-Funktion, die auf einem Begriff in der Standardsprache basiert, ein Datums-Suffix, das WordPress nicht lokalisieren kann, ein Slug, den der Erweiterte Übersetzungs-Editor nicht erfindet. In Support-Anfragen werden sie als Bugs gemeldet; das sind sie aber nicht. Diese Seite erklärt, was passiert, warum und was Sie stattdessen tun können.

has_category() und andere bedingte Tags in übersetzten Beiträgen

Der Core von WordPress filtert has_category() absichtlich nicht durch WPML. Bei einer Übersetzung ist die Kategorie der übersetzte Begriff, der seinen eigenen Slug hat, sodass has_category('news') im französischen Beitrag „false“ ist, obwohl sich der französische Beitrag in der französischen Kategorie „news“ befindet. Das Gleiche gilt für has_term(), in_category() und jeden Code, der einen Slug oder eine Term-ID der Standardsprache vergleicht. Rufen Sie die Bedingung mit dem übersetzten Slug auf oder lösen Sie die Term-ID zuerst über den Filter wpml_object_id auf.

Was Sie sehen

Die native WordPress-Funktion has_category funktioniert nicht für übersetzte Beiträge.

Ein Beispiel dafür ist Folgendes:

1. Wir haben eine Kategorie mit dem englischen Slug „test“ und ihrer französischen Übersetzung „test-fr“.
2. Diese Kategorie ist Beiträgen zugewiesen.
3. Wenn Sie has_category("test") innerhalb eines Loops in der Datei single.php Ihres Themes aufrufen, gibt es für die Standardsprache true zurück, für die Übersetzung jedoch false.

Was Sie tun können

Definieren Sie einen neuen Filter in der Datei functions.php Ihres Themes:

function wp_has_category ($category) {
$category = get_term_by('name', $category, 'category');
return has_category($category);
}
add_filter('wp_has_category', 'wp_has_category', 10, 1);

Ersetzen Sie die Funktion has_category durch diesen neuen Filter:

apply_filters( 'wp_has_category', 'test' )

Dieser Filter nimmt die übersetzte Kategorie basierend auf dem Namen der ursprünglichen Kategorie und prüft, ob die übersetzte Kategorie einem Beitrag zugewiesen ist.

Referenz: wpmlcore-3024.

Datums-Suffixe (1st, 2nd, 3rd) sind nicht übersetzbar

Dies ist eine Einschränkung des WordPress-Cores, nicht von WPML: Das Suffix stammt aus der Datumsformatierung von PHP und durchläuft niemals eine Übersetzungsfunktion.

Was Sie sehen

Einige Themes oder Plugins verwenden die WordPress-Funktionen wp_date() oder date_i18n(), um Daten anzuzeigen. Diese Daten können ein Suffix wie 1st oder 26th verwenden, abhängig von den ausgewählten Parametern.

Derzeit ist es aufgrund einer seit Langem bekannten Einschränkung im WordPress-Core nicht möglich, Datums-Suffixe zu übersetzen.

Was Sie tun können

Als Problemumgehung können Sie den Filter wp_date verwenden, um das Datum abzurufen, und dann das Suffix ändern, bevor es auf der Seite gerendert wird. Bitte erstellen Sie ein vollständiges Backup Ihrer Website, bevor Sie fortfahren, und befolgen Sie die folgenden Schritte:

• Fügen Sie der Datei functions.php Ihres Themes einen kleinen wp_date-Filter hinzu, der jedes Suffix als String registriert (icl_register_string) und seine Übersetzung (icl_t) anstelle des englischen Suffixes zurückgibt:


• Öffnen Sie die Seite, auf der die Daten angezeigt werden. Dadurch wird der hinzugefügte Filter ausgeführt.


• Gehen Sie zu WPML → String-Übersetzung und übersetzen Sie die Daten.


• Sie müssen jedes Suffix einzeln übersetzen (z. B. 1st, 2nd…), da es sich je nach Sprache ändern kann.

Referenz: compsupp-5773.

Der Erweiterte Übersetzungs-Editor erfindet keinen Slug

Der Editor übersetzt das Slug-Feld, wenn Sie es ausfüllen, und behält den ursprünglichen Slug bei, wenn Sie es leer lassen. Er leitet niemals von sich aus einen Slug aus dem übersetzten Titel ab.

Was Sie sehen

Wenn Sie einen Beitrag mit unserem Erweiterten Übersetzungs-Editor übersetzen, wird das Slug-Feld nicht automatisch ausgefüllt. Wenn Sie sich dann entscheiden, das Slug-Feld leer zu lassen, wird der Slug der Originalsprache in den übersetzten Beitrag geladen.

Referenz: wpmlsupp-8574.

Page-Builder-Shortcodes in einer WooCommerce-Produktkurzbeschreibung

Die Kurzbeschreibung ist der Textauszug des Beitrags, laut WordPress-Definition ein reines Textfeld, daher parst WPML darin keine Page-Builder-Shortcodes so, wie es das im Inhalt tut. WooCommerce rendert sie zufällig, weshalb diese Diskrepanz die Leute überrascht.

Was Sie sehen

Die WooCommerce-Produktkurzbeschreibung basiert auf dem Feld für den Textauszug des Beitrags, und das ist normalerweise ein einfaches Textfeld, das keine Shortcodes verarbeitet. Daher ist nicht zu erwarten, dass Page-Builder-Shortcodes funktionieren, wenn Sie sie in den Textauszug des Beitrags einfügen, und beim Übersetzen von Beitragsauszügen versucht WPML nicht, solche Shortcodes zu verarbeiten.

Aber WC behandelt diese „Auszüge“ etwas anders, und Shortcodes funktionieren tatsächlich, jedoch verhält sich WPML weiterhin so, als ob sie es nicht tun würden. Wenn der Shortcode Attribute enthält, die übersetzt werden müssen, oder interne Links, die automatisch gehandhabt werden sollten, ist das nicht ohne Weiteres möglich.

Was Sie tun können

Wir haben Code vorbereitet, der als Plugin hinzugefügt werden kann, um diese Funktionalität bereitzustellen. Kopieren Sie den folgenden Code, fügen Sie ihn in eine Datei ein, die Sie beispielsweise wpmlpb-excerpts.php nennen, speichern Sie sie in Ihrem Verzeichnis wp-content/plugins/ und aktivieren Sie dann das Plugin.

<?php
/**
 * Plugin Name: WPML Page Builders - Proces Excerpts
 * Description: Parses shortcode strings in exceprts.
 * Version: 1.0
 */
namespace WPMLPB686;

( new Excerpts() )->add_hooks();

class Excerpts {

	const SEPARATOR_START = '<!--WPML_EXCERPT_START-->';
	const SEPARATOR_END   = '<!--WPML_EXCERPT_END-->';

	public function add_hooks() {
		add_filter( 'wpml_pb_shortcode_content_for_translation', [ $this, 'joinWithContent' ], 10, 2 );
		add_filter( 'wpml_tm_translation_job_data', [ $this, 'excludeFromJob' ], 10, 2 );
		add_action( 'wpml_pro_translation_completed', [ $this, 'splitFromContent' ], 999 );
	}

	public function joinWithContent( $content, $id ) {
		$post = get_post( $id );
		if ( $post && $post->post_excerpt ) {
			$content .= self::SEPARATOR_START . $post->post_excerpt . self::SEPARATOR_END;
		}

		return $content;
	}

	public function excludeFromJob( $package, $post ) {
		if ( preg_match( '/[[^]]+]/', $post->post_excerpt ) ) {
			$package['contents']['excerpt']['translate'] = 0;
			$package['contents']['excerpt']['data']      = '';
		}

		return $package;
	}

	public function splitFromContent( $post_id ) {
		$post = get_post( $post_id );
		if ( $post && false !== strpos( $post->post_content, self::SEPARATOR_START ) ) {
			$start_pos = strpos( $post->post_content, self::SEPARATOR_START );
			$end_pos   = strpos( $post->post_content, self::SEPARATOR_END, $start_pos );

			if ( false !== $end_pos ) {
				$content = substr( $post->post_content, 0, $start_pos );
				$excerpt = substr( $post->post_content, $start_pos + strlen( self::SEPARATOR_START ), $end_pos - $start_pos - strlen( self::SEPARATOR_START ) );

				if ( $excerpt ) {
					wp_update_post(
						[
							'ID'           => $post_id,
							'post_content' => $content,
							'post_excerpt' => $excerpt,
						]
					);
				}
			}
		}
	}
}

Referenz: wpmlpb-686.

Eine andere Domain pro Sprache beim WordPress.com-Hosting

WordPress.com ordnet einer Website eine Domain zu; das URL-Format „Eine andere Domain pro Sprache“ erfordert, dass jede Sprachdomain dasselbe WordPress erreicht, was dieses Hosting nicht anbietet.

Was Sie sehen

Aufgrund von Einschränkungen bei der Funktionsweise des Domain-Mappings mit WordPress.com ist es nicht möglich, die Sprach-URL-Einstellung so zu wählen, dass eine andere Domain pro Sprache verwendet wird, wenn Websites dort gehostet werden.

Was Sie tun können

Anstelle einer anderen Domain pro Sprache kann eine der anderen Sprach-URL-Optionen verwendet werden, bei denen Sprachen in Verzeichnissen liegen oder als URL-Parameter hinzugefügt werden.

Ein anderer Host wäre erforderlich, wenn eine andere Domain pro Sprache eine Voraussetzung wäre.

Referenz: wpmltriage-2045.

Importierte Übersetzungen und die Übersetzungs-Editoren

Ein Import schreibt fertige Übersetzungen; er erstellt keine Übersetzungsaufträge, und die Editoren arbeiten auf Basis von Aufträgen. Die Übersetzungen sind im Frontend vollständig und im Erweiterten oder Klassischen Übersetzungs-Editor einfach nicht bearbeitbar.

Was Sie sehen

Wann immer Sie Inhalte mit WP All Import und dem Add-on WPML All Import importieren, sehen Sie die importierten Beitragsübersetzungen fehlerfrei im Frontend. Sie werden jedoch auf Probleme stoßen, wenn Sie versuchen, sie mit den Übersetzungs-Editoren von WPML zu aktualisieren:

• Der Klassische Übersetzungs-Editor zeigt Inhalte in der Standardsprache anstelle der importierten Übersetzungen an
• Der Erweiterte Übersetzungs-Editor zeigt leere Übersetzungen an

Das liegt daran, dass WPML beim Importieren mehrsprachiger Inhalte keine Übersetzungsaufträge erstellt, die für die String-Segmentierung erforderlich sind.

Was Sie tun können

Um Ihre importierten Übersetzungen zu bearbeiten oder zu aktualisieren, wechseln Sie bitte zum nativen WordPress-Editor und verwenden Sie die manuelle Übersetzung.

Referenz: WPMLAI-168.