Sprachkonfigurationsdateien

Amir

Aktualisiert: Februar 23, 2023

WPML kann eine Konfigurationsdatei lesen, die ihm mitteilt, was in Themes und Plugins übersetzt werden muss. Die Datei heißt wpml-config.xml und wird im Stammordner des Plugins oder Themes abgelegt.

Inhalt

Der Zweck der Sprachkonfigurationsdatei
Automatische Generierung der Datei wpml-config.xml
Struktur und Syntax
Verwendung der WPML-Sprachkonfigurationsdatei mit untergeordneten Themes

Zweck

Um die Kompatibilität mit WPML zu erreichen, sollten Sie auch eine Konfigurationsdatei erstellen, die Ihnen bei der Aufrechterhaltung der Kompatibilität in Ihren zukünftigen Versionen helfen wird. WPML kann alles auf Ihrer WordPress-Website übersetzen, aber Sie müssen ihm sagen, was übersetzt werden muss. Diese Datei tut dies.

Gehen Sie auf die Seite WPML → Einstellungen.

Diese Seite teilt WPML alles mit, was es wissen muss, einschließlich der zu übersetzenden oder zu synchronisierenden benutzerdefinierten Felder, der mehrsprachigen benutzerdefinierten Beiträge und Taxonomien und sogar der zu übersetzenden Admin-Texte.

Die Sprachkonfigurationsdatei enthält diese Informationen, so dass sie nicht von jedem Benutzer manuell auf der Verwaltungsseite eingegeben werden müssen.

Für einige der Themes und Plugins hosten wir die Sprachkonfigurationsdateien auf unseren Servern. Eine Liste können Sie hier einsehen. Sie wird so eingestellt, dass sie die lokale Sprachkonfigurationsdatei überschreibt, die sich im Stammverzeichnis des Themes oder Plugins befindet.

Mit WPML können Sie auch manuell alle Einstellungen überschreiben, die von Theme- und Plugin-Sprachkonfigurationsdateien geladen werden. Dies gilt sowohl für die Sprachkonfigurationsdateien im Stammverzeichnis des Themes oder Plugins als auch für die Sprachkonfigurationsdateien, die auf unseren Servern gehostet werden.

Automatische Generierung der Datei wpml-config.xml

Wenn Sie mit der Erstellung von XML-Dateien nicht vertraut sind, hat unser Team das Plugin Multilingual Tools entwickelt, das Ihnen diese Aufgabe erleichtert. Obwohl es ursprünglich als Hilfsmittel für Theme- und Plugin-Autoren gedacht war, um ihre Produkte mehrsprachig zu machen, kann es auch ganz einfach verwendet werden, um Ihre eigene wpml-config.xml Datei zu erstellen.

Um mehr über die Erstellung Ihrer wpml-config.xml Datei zu erfahren, besuchen Sie die Seite des Plugins Multilingual Tools. Schauen Sie insbesondere in den Abschnitt Wie generiere ich Sprachkonfigurationsdateien mit Hilfe der Multilingual Tools?

Sobald Sie die Konfigurationsdatei haben, fügen Sie sie in das Stammverzeichnis Ihres Themes ein. Wenn Sie bereits eine haben, überschreiben Sie sie nicht. Bearbeiten Sie stattdessen Ihre ursprüngliche XML-Datei und fügen Sie den mit dem Plugin Multilingual Tools generierten Code hinzu.

Bitte beachten Sie, dass dieses Plugin nicht für den Einsatz auf Produktionsseiten gedacht ist.

Um dieses Tutorial zu lesen und Sprachkonfigurationsdateien für Ihre Themes und Plugins zu erstellen, können Sie mit diesem Beispiel beginnen – wpml-config.zip.

Sie müssen sie bearbeiten, können aber die Abschnitte und die Struktur dieser Datei verwenden.

Struktur und Syntax

Der Inhalt der Datei wpml-config.xml muss in diese Tags verpackt werden

<wpml-config>

und

</wpml-config>

Derzeit können Sie die folgenden Daten- und Übersetzungseinstellungen in dieser Konfigurationsdatei konfigurieren:

Inhalt des Seitenerstellers
Benutzerdefinierte Felder
Benutzerdefinierte Begriffe
Benutzerdefinierte Typen
Benutzerdefinierte Taxonomien
Gutenberg-Blöcke
Verwaltungstexte / wp_options
Konfiguration des Sprachumschalters

1. Shortcodes und Page Builder-Inhalte

Mit WPML können Sie die Datei wpml-config.xml verwenden, um Shortcodes zu definieren, die der Inhaltsübersetzung hinzugefügt werden müssen.

In den folgenden Beispielen zeigen wir Ihnen, wie Sie Shortcodes für den Seitenersteller registrieren können. Sie können die gleiche Codestruktur verwenden, um alle Arten von Shortcodes für die Übersetzung zu registrieren.

1.1 Strings übersetzen

Nehmen wir ein Beispiel, bei dem Sie mit Visual Composer einen Texttrenner zu einer Seite hinzugefügt haben. Dieses Trennzeichen hat einen Titel, und sein Shortcode sieht wie folgt aus:

[vc_text_separator title="Separator Title"]

Um den Titel dieses Texttrenners zu übersetzen, müssen wir unserer Datei wpml-config.xml ein paar Zeilen hinzufügen. Auf diese Weise „weiß“ WPML, dass der Titel des Separators übersetzt werden muss. Dies geschieht nach der gleichen Logik wie bei den benutzerdefinierten Beitragstypen, benutzerdefinierten Feldern und anderen.

Der folgende Code ist ein Beispiel dafür, was wir in diesem Fall der Datei wpml-config.xml hinzufügen müssen.

Schauen wir uns die Struktur des obigen Beispiels an:

Beginnen Sie mit dem Shortcode-Tag. Alle Shortcodes auf Ihrer Website, die übersetzt werden müssen, sollten unter diesem Tag abgelegt werden.
Verwenden Sie dann den Shortcode-Tag, um alle zu einem einzigen Shortcode gehörenden Tags einzuschließen.
Der Tag namens tag wird verwendet, um den Namen des Shortcodes zu definieren. In diesem Fall ist es der vc_text_separator. Sie können benutzerdefinierte Bezeichnungen hinzufügen, die sowohl im Erweiterten Übersetzungseditor als auch im Klassischen Übersetzungseditor angezeigt werden. Diese Beschriftungen werden auch beim Exportieren in XLIFF-Dateien berücksichtigt. Siehe das folgende Beispiel für Tag- und Attributbeschriftungen.
Da Shortcodes ein oder mehrere Attribute haben können, verpacken wir sie in den attributes (Plural) Tag und verwenden den attribute (Singular) Tag, um den Titel jedes Attributs zu definieren.

Seitenersteller enthalten (manchmal) Designelemente, die Link-Attribute haben.

Sie können interne Links automatisch auf die übersetzte Version dieses Beitrags verweisen lassen, indem Sie die neue Shortcode-Link-Option in der Datei wpml-config.xml verwenden: type=“link“.

Sie können das Attribut encoding mit diesem Attribut verwenden. Es behandelt die spezielle Kodierung, die verschiedene Seitenersteller verwenden. Das Kodierungsattribut ist in der Regel spezifisch für den verwendeten Page Builder. Er akzeptiert die folgenden Werte:

base64 – Visual Composer raw HTML shortcode. Der HTML-Code wird als base64-String im Shortcode gespeichert.
vc_link – Spezielle Link-Formatierung für Visual Composer.
av_link – Spezielle Link-Formatierung für Enfold.
allow_html_tags – Normalerweise werden HTML-Tags aus den Shortcode-Attributen entfernt. Setzen Sie encoding auf allow_html_tags, wenn das Shortcode-Attribut HTML-Tags zulassen soll. Dies sollte mit Vorsicht verwendet werden, da die Zulassung von HTML-Tags in manchen Situationen die Formatierung beeinträchtigen und ein Sicherheitsproblem darstellen kann.

Wenn Sie darüber nachdenken, urlencodierte Shortcodes zu verwenden, lesen Sie unbedingt die Seite über das Übersetzen urlencodierter Shortcodes.

Durch das Hinzufügen von Beschriftungen zu Tags und Attributen können Sie benutzerdefinierte Beschriftungen im erweiterten Übersetzungseditor oder im klassischen Übersetzungseditor anzeigen. Dies kann dem Übersetzer helfen, den Kontext der Strings besser zu verstehen.

Definition von benutzerdefinierten Shortcode-Bezeichnungen im erweiterten Übersetzungseditor

1.2 Medien übersetzen

Sie können WPML Media Translation verwenden, um Bilder in Page Builder-Inhalten zu übersetzen. Dies geschieht durch Umwandlung von Bild-IDs und Bild-URLs. Es ist notwendig, dem Page Builder, der Shortcodes verwendet, mitzuteilen, wie er diese Umwandlung vornehmen soll. Der folgende Code ist ein Beispiel dafür, was wir in diesem Fall der Datei wpml-config.xml hinzufügen müssen.

Sie können die folgenden Werte verwenden:

ignore-content – Kann innerhalb eines Tag-Elements verwendet werden. Dieser Wert ist optional und kann entweder 0 oder 1 sein. Sie können dieses Attribut verwenden, um Abwärtskompatibilität für neue Medien-Shortcodes zu erreichen. Wenn der Wert auf 1 gesetzt ist, wird der Inhalt des Shortcodes nicht verarbeitet.
type – Kann innerhalb eines Tag-Elements verwendet werden. Sie können auch Shortcode-Inhalte verwenden, die die URL der Medien als optionalen Wert in media-url enthalten.
type – kann auch innerhalb eines Attributelements verwendet werden. In diesem Fall kann er einen der folgenden optionalen Werte haben:
- media-ids – eine durch Kommata getrennte Liste von Medien-IDs.
- media-url – URL des Mediums
- link – verweist auf eine andere Seite der Website und wird von WPML automatisch in die URL der übersetzten Seite umgewandelt

1.3 Widgets für den Seitenersteller übersetzen

Ab WPML 4.4.4 können Sie nun Page-Builder-Widgets in Ihrer Sprachkonfigurationsdatei registrieren. Bitte lesen Sie unsere Dokumentationsseite über die Registrierung von Widgets für den Seitenersteller für die Übersetzung.

1.4 Automatisches Konvertieren von Shortcode-IDs

Ab WPML 4.5.9 können Sie die IDs von Beiträgen oder Taxonomiebegriffen in Shortcode-Attributen deklarieren. Diese IDs können dann automatisch im Frontend Ihrer Website umgewandelt werden.

Zum Beispiel, wenn man den folgenden Shortcode betrachtet:

[foo_product_list product_ids="12,34,56"]

Wir können erklären, dass das product_ids-Attribut Post-IDs mit der folgenden Konfiguration enthält:

&lt;Shortcode&gt;
    &lt;tag ignore-content="1"&gt;foo_product_list&lt;/tag&gt;
    &lt;attributes&gt;
        &lt;attribut type="post-ids" sub-type="product"&gt;product&lt;/attribute&gt;
    &lt;/attributes&gt;
&lt;/shortcode&gt;

Im Frontend wird der Shortcode automatisch umgewandelt:

[foo_product_list product_ids="13,35,57"]

Sie können die folgenden Konfigurationsattribute verwenden:

Typ – entweder post-ids oder taxonomy-ids
sub-type (optional) – kann die spezifische Entität des Typs sein, wenn sie bereits bekannt ist. Zum Beispiel „product“ für den benutzerdefinierten Beitragstyp „Product“. Wenn sie nicht definiert ist, wird die spezifische Entität erraten.

Die ID-Konvertierung ist vielseitig und versucht, sich an die meisten möglichen Formate von IDs anzupassen (einzelne ID, Liste von IDs, serialisiertes Array, JSON-kodiertes Array).

2. Benutzerdefinierte Felder

Der Name des benutzerdefinierten Feldes muss angegeben werden und auch die Aktion, die WPML ausführen soll: übersetzen, kopieren, einmalig kopieren, ignorieren.

Dieser Block muss unter dem Tag <wpml-config> eingefügt werden.

Sie können die folgenden Übersetzungsoptionen für benutzerdefinierte Felder festlegen:

translate: Ermöglicht es dem Benutzer, den Wert des benutzerdefinierten Feldes zu übersetzen. Diese Felder werden auf dem Bildschirm des Übersetzungseditors angezeigt und können an einen der professionellen Übersetzungsdienste gesendet werden.
Kopieren: Diese Aktion kopiert den Wert des benutzerdefinierten Feldes der Standardsprache in die sekundären Sprachen. Das bedeutet, dass eine Aktualisierung des Wertes des benutzerdefinierten Feldes der Standardsprache immer in die zweite Sprache kopiert wird. Die auf “ Kopieren“ eingestellten benutzerdefinierten Felder werden nicht auf dem Bildschirm des Übersetzungseditors angezeigt.
Einmalig kopieren: Der Wert des benutzerdefinierten Feldes wird bei der Erstübersetzung in die Sekundärsprache kopiert. Die benutzerdefinierten Felder, die die Aktion „Einmalig kopieren“ verwenden, erscheinen nicht auf dem Bildschirm des Übersetzungseditors. Der Benutzer kann jedoch den Wert des benutzerdefinierten Feldes für die sekundäre Sprache ändern, so dass er sich von der Standardsprache unterscheidet, indem er den Bearbeitungsbildschirm für Beiträge verwendet. Dies ermöglicht es dem Benutzer, für übersetzte Inhalte andere Einstellungen zu verwenden als für die Beiträge und Seiten in der Standardsprache. Der Benutzer möchte zum Beispiel die Hintergrundfarbe desselben Elements in der Standardsprache auf gelb und in der zweiten Sprache auf blau einstellen. Bitte beachten Sie, dass die Bearbeitung eines Feldes, das auf „einmalig“ eingestellt ist, das Feld nicht als aktualisierungsbedürftig markiert. Der Grund dafür ist, dass das Feld nicht in eine bestehende Übersetzung kopiert wird, sondern erst bei der Erstellung der Übersetzung.
Ignorieren: Diese Aktion verhindert, dass das benutzerdefinierte Feld in die sekundäre Sprache kopiert wird.

Sie können Attribute zu den <custom-field> Tags hinzufügen. Mit diesen Attributen werden die Anweisungstexte im Erweiterten Übersetzungseditor oder im Klassischen Übersetzungseditor angepasst.

Stil kann Zeile, Textbereich oder visuell sein, um eine einzelne Zeile, einen Textbereich bzw. WYSIWYG darzustellen.
wird neben dem Feld angezeigt.
group gibt an, ob das benutzerdefinierte Feld zu einer Gruppe gehört und wie die Bezeichnung der Gruppe lauten soll. Wenn sich ein Feld in einer Gruppe befindet:

* das Feld wird aus dem Abschnitt für benutzerdefinierte Felder entfernt

* Das Feld wird dem Abschnitt der Bezugsgruppe hinzugefügt.

Sie können auch optionale Encode-Attribute hinzufügen, um die Kodierung gegenüber dem Standardwert(keine Kodierung) zu ändern. Das Attribut Encoding akzeptiert die folgenden Werte:

json
base64
urlencode

Mit dem Attribut können Sie mehrere Kodierungen verwenden. In diesem Fall müssen die Werte durch ein Komma getrennt werden, z. B. encoding="json,base64".

Wenn dieser wpml-config.xml-Inhalt verwendet wird, werden diese benutzerdefinierten Felder im erweiterten Übersetzungseditor oder im klassischen Übersetzungseditor angezeigt, wie in der folgenden Abbildung dargestellt.

Erweiterter Übersetzungseditor

Klassischer Übersetzungseditor

Benutzerdefinierte Feldbezeichnungen im erweiterten Übersetzungseditor

Benutzerdefinierte Feldbezeichnungen im klassischen Übersetzungseditor

2.1 Übersetzen von Unterschlüsseln in benutzerdefinierten Feldern

WPML übersetzt standardmäßig alle Unterschlüssel in benutzerdefinierten Feldern. Es ist möglich, dieses Verhalten zu umgehen, indem man angibt, welche Unterschlüssel übersetzt werden sollen.

Es ist auch möglich, Wildcards zu verwenden, wie sie für Admin-Texte verwendet werden:

Alle Unterfelder, die mit title- beginnen, mit dem Code abgleichen:
<key name="title-*" />
Entspricht allen Teilfeldern und wird im Allgemeinen verwendet, um einen Array-Index mit Code abzugleichen:
<key name="*" />
Um [{"title":"First title"},{"title":"Second title"}] zu erhalten, verwenden Sie den Code

3. Individuelle Attribute

Der Name des benutzerdefinierten Begriffs muss angegeben werden und auch die Aktion, die WPML ausführen soll: übersetzen, kopieren, einmalig kopieren, ignorieren.

Dieser Block muss unter dem Tag <wpml-config> eingefügt werden.

Sie können die folgenden Übersetzungsoptionen für benutzerdefinierte Felder festlegen:

translate: Ermöglicht es dem Benutzer, den Wert des benutzerdefinierten Begriffs zu übersetzen. Diese Begriffe werden auf dem Bildschirm des Übersetzungseditors angezeigt und können an einen der professionellen Übersetzungsdienste gesendet werden.
Kopieren: Diese Aktion kopiert den Wert des benutzerdefinierten Begriffs der Standardsprache in die sekundären Sprachen. Dies bedeutet, dass eine Aktualisierung des benutzerdefinierten Begriffswertes der Standardsprache immer in die sekundäre Sprache kopiert wird. Die auf „Copy“ eingestellten benutzerdefinierten Begriffe werden nicht auf dem Bildschirm des Übersetzungseditors angezeigt.
Copy Once: Der Wert des benutzerdefinierten Begriffs wird bei der Erstübersetzung in die Sekundärsprache kopiert. Die benutzerdefinierten Begriffe, die die Aktion „Copy Once“ verwenden, erscheinen nicht auf dem Bildschirm des Übersetzungseditors. Der Benutzer kann jedoch den Wert des benutzerdefinierten Begriffs für die sekundäre Sprache so ändern, dass er sich von der Standardsprache unterscheidet, indem er den Bearbeitungsbildschirm für Beiträge verwendet.
ignorieren: Diese Aktion verhindert, dass der benutzerdefinierte Begriff in die sekundäre Sprache kopiert wird.

4. Benutzerdefinierte Typen

Die benutzerdefinierten Beitragstypen, die WPML übersetzen soll.

Sie können das Attribut „display-as-translated“ zum Tag hinzufügen, um die Beitragstypen in der Standardsprache anzuzeigen, wenn keine Übersetzung existiert.

Sie können das Attribut „automatic“ zum Tag hinzufügen, um einen Beitragstyp von der automatischen Übersetzung auszuschließen, wenn Sie den Modus “ Alles übersetzen“ verwenden. Bitte beachten Sie, dass bei Verwendung dieses Attributs Ihre gesamte Sprachkonfigurationsdatei nur für die WPML-Versionen 4.5.0 und höher funktionieren wird.

5. Benutzerdefinierte Taxonomien

Die benutzerdefinierten Taxonomien, die Ihr Plugin möglicherweise verwendet und die bereits bei WP registriert sind.

Hinweis: Die Taxonomien, die nicht übersetzt werden müssen, können einfach aus dieser Liste gestrichen werden.

Sie können das Attribut „display-as-translated“ zum Tag hinzufügen, um die Taxonomien in der Standardsprache anzuzeigen, wenn keine Übersetzung existiert.

6. Gutenberg-Blöcke

Mit dem Gutenberg-Editor erstellen Sie Inhalte mithilfe von Blöcken.

Sie können festlegen, welche Teile Ihres Gutenberg-Blocks übersetzt werden müssen, indem Sie der Datei wpml-config.xml Einstellungen hinzufügen.

Xpath wird verwendet, um Teile des Textes zu definieren, die übersetzt werden müssen.

6.1 Registrierung von Gutenberg-Blöcken als übersetzbar

Nehmen wir an, wir haben ein Bild, das mit folgendem Code angezeigt wird:

Wir wollen die Attributwerte figcaption und alt dieses Bildes übersetzen.

Um dies zu erreichen, muss der folgende Code in die Datei wpml-config.xml eingefügt werden:

Bitte beachten Sie, dass der Typ core/image und nicht wp:image ist, da dies der Wert ist, der von der Block-API zurückgegeben wird.

Sie können festlegen, welche Gutenberg-Blockfelder Links sind. WPML ersetzt dann alle Links durch ihre Übersetzungen, sofern diese verfügbar sind.

6.2 Übersetzung von Blockattributen

Hier ist ein Beispiel für ein Format für die Definition eines Editor-Blocks:

Sie können das Schlüsselelement auf die gleiche Weise verwenden, wie es bei der Konfiguration von Admin-Texten / wp_options verwendet wird. Das bedeutet auch, dass Sie Schlüsselelemente innerhalb von übergeordneten Schlüsselelementen haben können.

Sie können das Attribut label verwenden, um optionale benutzerdefinierte Bezeichnungen hinzuzufügen, die im erweiterten Übersetzungseditor neben den Blockelementen angezeigt werden. Wenn das label-Attribut Teil des Gutenberg-Block-Tags ist, wird es als Fallback-Label für Elemente des Blocks verwendet, die kein spezifisches Label definiert haben.

Fallback-Label im erweiterten Übersetzungseditor

Das Attribut search-method kann einen von zwei Werten haben:

Wildcards (Standard)
regex.

Wildcards können auf die gleiche Weise verwendet werden wie für Admin-Texte. Dies bedeutet, dass ein Sternchen(*) im Attribut name verwendet werden kann. Hier ist ein Beispiel für einen Block:

Wir können die Blockdefinition mit einem Platzhalter festlegen:

So können wir „Der Titel“ und „Der Inhalt“ übersetzen, da dies die einzigen Attribute sind, die mit myp beginnen.

Mit regex können wir einen regulären Ausdruck im Attribut name verwenden. Dies kann bei komplexen Konfigurationen äußerst nützlich sein. Hier ist ein Beispiel für einen Block:

Wir können die Blockdefinition mit einem regulären Ausdruck festlegen:

So können wir „Der Titel“ und „Der Inhalt“ übersetzen, da dies die einzigen Attribute sind, die nicht mit _ beginnen.

Einige Block-Plugins speichern Daten in einer URL-kodierten JSON-String im Attribut eines Blocks. Mit dem Attribut encoding können Sie die Zeichenfolge dekodieren und ihre Unterschlüssel für die Übersetzung registrieren.

Das LazyBlocks-Plugin speichert beispielsweise den Inhalt von Repeater-Feldern in einem kodierten JSON-String:

Sie können die Unterschlüssel vorname und nachname mit der folgenden XML-Konfiguration registrieren:

6.3 Block-Namensraum

Sie können eine globale Konfiguration für den Blocknamensraum haben.

Der Name des Blocks ist nicht länger ein erforderlicher Teil der Definition.

Wenn die Blockkonfiguration für alle Blöcke in einem Namensraum gleich ist, kann sie wie folgt geschrieben werden:

6.4 IDs in Blöcken automatisch konvertieren

Die ID-Konvertierung ist vielseitig und versucht, sich an die meisten möglichen Formate von IDs anzupassen (einzelne ID, Liste von IDs, serialisiertes Array, JSON-kodiertes Array).

Betrachten Sie den folgenden Block:

&lt;!-- wp:foo/form {"ids":[27,28]} --&gt;
&lt;div class="wp-block-foo-form-wrap"&gt;
	&lt;form class="foo-form" action="" method="post"&gt;
		&lt;input type="hidden" name="foo_form_post_ids" value="27,28" /&gt;
		&lt;input type="submit" /&gt;
	&lt;/form&gt;
&lt;/div&gt;
&lt;!-- /wp:foo/form --&gt;

Wir können das Blockattribut ids und den Wert des HTML-Tag-Attributs foo_form_post_ids wie folgt als Post-IDs deklarieren:

&lt;gutenberg-block type="foo/form" translate="0"&gt;
  &lt;key name="ids"&gt;
    &lt;key name="*" type="post-ids" sub-type="post" /&gt;
  &lt;/key&gt;
  &lt;xpath type="post-ids" sub-type="post"&gt;//*[@name="foo_form_post_ids"]/@value&lt;/xpath&gt;
&lt;/gutenberg-block&gt;

Der Block wird mit der höchsten Priorität in den Filter render_block_data umgewandelt (siehe unten):

&lt;!-- wp:foo/form {"ids":[42,43]} --&gt;
&lt;div class="wp-block-foo-form-wrap"&gt;
	&lt;form class="foo-form" action="" method="post"&gt;
		&lt;input type="hidden" name="foo_form_post_ids" value="42,43" /&gt;
		&lt;input type="submit" /&gt;
	&lt;/form&gt;
&lt;/div&gt;
&lt;!-- /wp:foo/form →

Sie können die folgenden Konfigurationsattribute verwenden:

type – kann post-ids oder taxonomy-ids sein
sub-type (optional): kann die spezifische Entität des Typs sein, wenn sie bereits bekannt ist. Zum Beispiel „product“ für den benutzerdefinierten Beitragstyp „Product“. Wenn nicht definiert, wird die spezifische Entität erraten.

7. Verwaltungstexte / wp_options

Strings, die Teil der Optionen sind, die die Plugins oder Themes in der Tabelle wp_options speichern.

Wenn Themes und Plugins get_option verwenden, lesen sie Werte aus der Tabelle wp_options. WPML kann diese Aufrufe filtern und eine Übersetzung der Werte dieser Optionen bereitstellen.

Dies funktioniert, wenn der wp_option-Datensatz ein einfacher String ist, aber auch, wenn es sich um ein serialisiertes Array handelt.

Um eine einzelne Option zu übersetzen, fügen Sie einen Schlüsseleintrag unter admin-texts hinzu. Um ein serialisiertes Array zu übersetzen, fügen Sie mehrere Schlüssel unter einem Schlüssel hinzu, wie im Beispiel my_plugin_options unten zu sehen ist.

Es ist möglich, den Platzhalter * in Unterschlüsseln wie im folgenden Fall zu verwenden.

Es ist gleich dieser Code:

Bitte beachten Sie, dass der Platzhalter * in übergeordneten Schlüsseln NICHT funktioniert:

8. Konfiguration des Sprachumschalters

Ermöglicht eine spezifische Konfiguration für den in WPML integrierten Sprachumschalter. Sie kann auch dazu verwendet werden, die Konfiguration des Sprachumschalters zurückzusetzen, wenn sie vom Backend aus geändert wurde (von den ursprünglichen Werten).

Um die neuen Änderungen zu sehen, klicken Sie bitte auf die Schaltfläche Standard wiederherstellen unten auf der Seite WPML → Sprachen.

Es müssen nicht alle diese Abschnitte in der Konfigurationsdatei vorhanden sein, sondern nur die, die für Ihr Plugin oder Theme zutreffen.

Verwendung der WPML-Sprachkonfigurationsdatei mit untergeordneten Themes

Wenn Sie ein untergeordnetes Thema verwenden, hat die Sprachkonfigurationsdatei des übergeordneten Themas Vorrang vor derjenigen des untergeordneten Themas. WPML bietet eine Konfigurationsseite, die es Ihnen ermöglicht, diese Einstellungen einfach zu überschreiben.

Betrachten wir ein Beispiel, bei dem die Sprachkonfigurationsdatei des übergeordneten Themes den benutzerdefinierten Beitragstyp „Property“ als übersetzbar einstellt.

Die übergeordnete Sprachkonfigurationsdatei setzt die Eigenschaft custom post type auf translate

Wenn Sie ein Child-Theme verwenden und den benutzerdefinierten Beitragstyp „Property“ als nicht übersetzbar festlegen möchten, navigieren Sie zur Seite WPML → Einstellungen und klicken Sie auf die Registerkarte Benutzerdefinierte XML-Konfiguration. Verwenden Sie den Editor, um den benutzerdefinierten Beitragstyp „Eigenschaft“ als nicht übersetzbar einzustellen. Setzen Sie einfach den Wert des Attributs translate auf 0 statt auf 1.

Überschreiben der Sprachkonfigurationseinstellungen des übergeordneten Themas

Die Einstellungen auf der Registerkarte Benutzerdefinierte XML-Konfiguration haben Vorrang vor den Einstellungen in der Sprachkonfigurationsdatei im übergeordneten Thema.