Fichiers de configuration de la langue

Amir

Mis à jour: février 21, 2023

WPML peut lire un fichier de configuration qui lui indique ce qui doit être traduit dans les thèmes et les plugins. Le fichier s’appelle wpml-config.xml et il est placé dans le dossier racine du plugin ou du thème.

Contenu

L’objectif du fichier de configuration de la langue
Génération automatique du fichier wpml-config.xml
Structure et syntaxe
Utilisation du fichier de configuration de la langue WPML avec des thèmes enfants

Objectif

Dans le cadre de la réalisation de la compatibilité avec WPML, vous devez également créer un fichier de configuration qui vous aidera à maintenir la compatibilité dans vos futures versions. WPML peut traduire tout ce qui se trouve sur votre site WordPress, mais vous devez lui indiquer ce qui doit être traduit. C’est ce que fait ce dossier.

Accédez à la page WPML → Paramètres.

Cette page indique à WPML tout ce qu’il doit savoir, notamment quels champs personnalisés doivent être traduits ou synchronisés, quels messages personnalisés et taxonomies doivent être multilingues et même quels textes d’administration doivent être traduits.

Le fichier de configuration de la langue inclut ces informations afin que chaque utilisateur ne doive pas les saisir manuellement dans la page d’administration.

Pour certains thèmes et plugins, nous hébergeons les fichiers de configuration de la langue sur nos serveurs. Vous pouvez voir une liste ici. Il est défini pour remplacer le fichier de configuration de la langue locale qui est placé dans le dossier racine du thème ou du plugin.

WPML vous permet également de remplacer manuellement tous les paramètres chargés par les fichiers de configuration de langue des thèmes et des plugins. Cela s’applique à la fois aux fichiers de configuration de la langue situés dans le dossier racine du thème ou du plugin et aux fichiers de configuration de la langue hébergés sur nos serveurs.

Génération automatique du fichier wpml-config.xml

Si vous n’êtes pas familier avec la création de fichiers XML, notre équipe a créé le plugin Multilingual Tools qui facilite cette tâche. Bien qu’il ait été initialement conçu comme un outil destiné à aider les auteurs de thèmes et de plugins à rendre leurs produits multilingues, il peut facilement être utilisé pour générer votre propre fichier wpml-config.xml .

Pour en savoir plus sur la génération de votre fichier wpml-config.xml, consultez la page du plugin Multilingual Tools. Plus précisément, consultez la section Comment générer des fichiers de configuration de langue à l’aide des outils multilingues ?

Une fois que vous avez le fichier de configuration, ajoutez-le à la racine du dossier de votre thème. Si vous en avez déjà un, ne l’écrasez pas. Au lieu de cela, modifiez votre fichier XML d’origine et ajoutez le code généré par le plugin Outils Multilingues.

Veuillez noter que ce plugin n’est pas destiné à être utilisé sur les sites de production en direct.

Pour lire ce tutoriel et construire des fichiers de configuration de langue pour vos thèmes et plugins, vous pouvez commencer par cet exemple – wpml-config.zip.

Vous devrez le modifier, mais vous pouvez utiliser les sections et la structure de ce fichier.

Structure et syntaxe

Le contenu du fichier wpml-config.xml doit être enveloppé dans ces balises

<wpml-config>

</wpml-config>

Actuellement, vous pouvez configurer les paramètres de données et de traduction suivants dans ce fichier de configuration :

Contenu du constructeur de pages
Champs personnalisés
Termes personnalisés
Types personnalisés
Taxonomies personnalisées
Blocs Gutenberg
Textes d’administration / wp_options
Configuration du sélecteur de langue

1. Shortcodes et contenu du constructeur de pages

WPML vous permet d’utiliser le fichier wpml-config.xml pour définir les shortcodes qui doivent être ajoutés à la traduction du contenu.

Dans les exemples ci-dessous, nous vous montrons comment enregistrer les shortcodes du constructeur de pages. Vous pouvez utiliser la même structure de code pour enregistrer tous les types de shortcodes pour la traduction.

1.1 Traduire des chaînes de caractères

Prenons un exemple où vous avez ajouté un séparateur de texte à une page à l’aide de Visual Composer. Ce séparateur a un titre, et son shortcode ressemble à ceci :

[vc_text_separator title="Separator Title"]

Afin de traduire le titre de ce séparateur de texte, nous devons ajouter quelques lignes à notre fichier wpml-config.xml. De cette façon, WPML « saura » que le titre de ce séparateur doit être traduit. Cela suit en fait la même logique que celle utilisée pour les types de messages personnalisés, les champs personnalisés et autres.

Le code suivant est un exemple de ce que nous devons ajouter au fichier wpml-config.xml dans ce cas.

Reprenons la structure de l’exemple ci-dessus :

Commencez par la balise shortcodes. Tous les shortcodes de votre site qui doivent être traduits doivent être placés sous cette balise.
Utilisez ensuite la balise shortcode pour regrouper toutes les balises appartenant à un seul et unique shortcode.
La balise appelée tag est utilisée pour définir le nom du shortcode. Dans ce cas, il s’agit du séparateur vc_text_separator. Vous pouvez ajouter des étiquettes personnalisées en option à afficher dans l’éditeur de traduction avancé ou l’éditeur de traduction classique. Ces étiquettes sont également incluses lors de l’exportation vers des fichiers XLIFF. Voir l’exemple ci-dessous sur les étiquettes des balises et des attributs.
Les codes courts peuvent avoir un ou plusieurs attributs, nous les enveloppons donc dans la balise attributes (pluriel) et utilisons la balise attribute (singulier) pour définir le titre de chaque attribut.

Les créateurs de pages incluent (parfois) des éléments de conception qui ont des attributs de lien.

Vous pouvez faire en sorte que les liens internes pointent automatiquement vers la version traduite de l’article en question en utilisant la nouvelle option de lien du shortcode du fichier wpml-config.xml: type= »link ».

Vous pouvez utiliser l’attribut encodage avec celui-ci. Il gère l’encodage spécial que divers constructeurs de pages utilisent. L’attribut d’encodage est généralement spécifique au constructeur de pages utilisé. Il accepte les valeurs suivantes :

base64 – Shortcode HTML brut de Visual Composer. Le HTML est stocké comme une chaîne base64 dans le shortcode.
vc_link – Formatage spécial des liens pour Visual Composer.
av_link – Formatage spécial des liens pour Enfold.
allow_html_tags – Normalement, les balises HTML sont supprimées des attributs des shortcodes. Définissez l’encodage à allow_html_tags si l’attribut du shortcode doit autoriser les balises HTML. Cette option doit être utilisée avec prudence, car autoriser les balises HTML dans certaines situations peut perturber le formatage et poser un problème de sécurité.

Si vous envisagez d’utiliser des codes courts codés en url, assurez-vous de lire la page sur la traduction des codes courts codés en url.

L’ajout d’étiquettes aux balises et aux attributs vous permet d’afficher des étiquettes personnalisées dans l’éditeur de traduction avancé ou l’éditeur de traduction classique. Cela peut aider le traducteur à mieux comprendre le contexte de la chaîne de caractères.

Définition d'étiquettes de code court personnalisées dans l'éditeur de traduction avancé — Définition d’étiquettes de code court personnalisées dans l’éditeur de traduction avancé

1.2 Traduire les médias

Vous pouvez utiliser WPML Media Translation pour traduire les images dans le contenu du constructeur de pages. Cela se fait par la conversion des ID d’images et des URL d’images. Il est nécessaire d’indiquer au constructeur de pages qui utilise des shortcodes comment effectuer cette conversion. Le code suivant est un exemple de ce que nous devons ajouter au fichier wpml-config.xml dans ce cas.

Vous pouvez utiliser les valeurs suivantes :

ignore-content – Peut être utilisé dans un élément de balise. Cette valeur est facultative et peut être soit 0 soit 1. Vous pouvez utiliser cet attribut pour obtenir une compatibilité ascendante pour les nouveaux shortcodes de médias. Si la valeur est fixée à 1 , le contenu du shortcode ne sera pas traité.
type – Peut être utilisé dans un élément de balise. Vous pouvez également utiliser le contenu du shortcode qui contient l’URL du média comme valeur optionnelle dans media-url.
type – peut également être utilisé dans un élément d’attribut. Dans ce cas, il peut avoir l’une des valeurs facultatives suivantes :
- media-ids – une liste d’identifiants de médias séparés par des virgules.
- media-url – URL du média
- lien – pointe vers une autre page du site et WPML le convertira automatiquement en l’URL de la traduction de la page.

1.3 Traduire les widgets du constructeur de pages

Depuis la version 4.4.4 de WPML, vous pouvez désormais enregistrer des widgets de construction de pages dans votre fichier de configuration de la langue. Veuillez consulter notre page de documentation sur la manière d’enregistrer les widgets du constructeur de pages pour la traduction.

1.4 Conversion automatique des ID de shortcode

À partir de WPML 4.5.9, vous pouvez déclarer les ID des articles ou des termes de taxonomie situés dans les attributs des shortcodes. Ces identifiants peuvent ensuite être convertis automatiquement sur le front-end de votre site.

Par exemple, si l’on considère le shortcode suivant :

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

Nous pouvons déclarer que l’attribut product_ids contient les ID des messages avec la configuration suivante :

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

Sur le front-end, le shortcode sera automatiquement converti en :

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

Vous pouvez utiliser les attributs de configuration suivants :

type – soit post-ids soit taxonomy-ids
sous-type (facultatif) – peut être l’entité spécifique du type si elle est déjà connue. Par exemple, product pour le type de message personnalisé Product. S’il n’est pas défini, l’entité spécifique sera devinée.

La conversion d’identifiants est polyvalente et tente de s’adapter à la plupart des formats d’identifiants possibles (identifiant unique, liste d’identifiants, tableau sérialisé, tableau encodé JSON).

2. Champs personnalisés

Le nom du champ personnalisé doit être fourni ainsi que l’action que WPML doit entreprendre : traduire, copier, copier une seule fois, ignorer.

Ce bloc devra être imbriqué sous la balise <wpml-config>.

Vous pouvez définir les options de traduction suivantes pour les champs personnalisés :

translate: permet à votre utilisateur de traduire la valeur du champ personnalisé. Ces champs s’affichent sur l’écran de l’éditeur de traduction et peuvent être envoyés à l’un des services de traduction professionnelle.
copier: cette action copie la valeur du champ personnalisé de la langue par défaut vers les langues secondaires. Cela signifie que la mise à jour de la valeur du champ personnalisé de la langue par défaut sera toujours copiée dans la langue secondaire. Les champs personnalisés définis pour la copie n’apparaissent pas sur l’écran de l’éditeur de traduction.
copy-once: la valeur du champ personnalisé est copiée dans la langue secondaire lors du processus de traduction initial. Les champs personnalisés qui utilisent l’action « copier une fois » n’apparaissent pas sur l’écran de l’éditeur de traduction. Toutefois, l’utilisateur peut modifier la valeur du champ personnalisé de la langue secondaire pour qu’elle soit différente de la langue par défaut en utilisant l’écran d’édition du message. Il est préférable de définir les champs personnalisés qui contiennent des paramètres tels que la couleur d’arrière-plan, la couleur de la police, la taille de la police, etc. Cela permet à l’utilisateur d’avoir des paramètres différents pour le contenu traduit que ceux définis pour les articles et les pages dans la langue par défaut. Par exemple, l’utilisateur souhaite que la couleur de fond du même élément soit jaune dans la langue par défaut et bleue dans la langue secondaire. Veuillez noter que l’édition d’un champ défini comme devant être copié une seule fois ne marquera pas le champ comme devant être mis à jour. En effet, le champ ne sera pas copié dans une traduction existante, mais uniquement lors de la création de la traduction.
ignorer: cette action permet d’éviter que le champ personnalisé ne soit copié dans la langue secondaire.

Vous pouvez ajouter des attributs aux balises <custom-field>. Ces attributs permettent de personnaliser les textes d’instruction dans l’éditeur de traduction avancé ou l’éditeur de traduction classique.

Le style peut être ligne, textarea ou visuel, pour afficher respectivement une ligne unique, une zone de texte ou WYSIWYG.
s’affiche à côté du champ.
group indique si le champ personnalisé appartient à un groupe et quel doit être le libellé du groupe. Lorsqu’un champ se trouve dans un groupe :

* le champ est supprimé de la section des champs personnalisés

* Le champ est ajouté à la section du groupe lié.

Vous pouvez également ajouter des attributs facultatifs encode pour modifier l’encodage par rapport à la valeur par défaut(aucun encodage). L’attribut Encoding accepte les valeurs suivantes :

json
base64
urlencode

Cet attribut vous permet d’utiliser plusieurs encodages. Dans ce cas, les valeurs doivent être séparées par une virgule, par exemple encoding="json,base64".

Lorsque ce contenu wpml-config.xml est utilisé, ces champs personnalisés sont affichés dans l’éditeur de traduction avancé ou l’éditeur de traduction classique, comme le montre l’image suivante.

Éditeur de traduction avancé

Éditeur de traduction classique

Étiquettes des champs personnalisés dans l’éditeur de traduction avancé

Libellés des champs personnalisés dans l’éditeur de traduction classique

2.1 Traduction des sous-clés dans les champs personnalisés

WPML traduit par défaut toutes les sous-clés des champs personnalisés. Il est possible de contourner ce comportement en spécifiant quelles sous-clés doivent être traduites.

Il est également possible d’utiliser des caractères génériques de la même manière que pour les textes administratifs:

Faites correspondre toutes les sous-zones commençant par titre- en utilisant le code :
<key name="title-*" />
Fait correspondre tous les sous-champs et est généralement utilisé pour faire correspondre un index de tableau en utilisant le code :
<key name="*" />
Pour obtenir [{"title":"First title"},{"title":"Second title"}], utilisez le code

3. Termes personnalisés

Le nom du terme personnalisé doit être fourni, ainsi que l’action que WPML doit entreprendre : traduire, copier, copier une seule fois, ignorer.

Ce bloc devra être imbriqué sous la balise <wpml-config>.

Vous pouvez définir les options de traduction suivantes pour les champs personnalisés :

translate: permet à votre utilisateur de traduire la valeur du terme personnalisé. Ces termes s’affichent sur l’écran de l’éditeur de traduction et peuvent être envoyés à l’un des services de traduction professionnels.
copier: cette action copie la valeur du terme personnalisé de la langue par défaut dans les langues secondaires. Cela signifie que la mise à jour de la valeur du terme personnalisé de la langue par défaut sera toujours copiée dans la langue secondaire. Les termes personnalisés définis pour la copie n’apparaissent pas sur l’écran de l’éditeur de traduction.
copy-once: la valeur du terme personnalisé est copiée dans la langue secondaire lors du processus de traduction initial. Les termes personnalisés qui utilisent l’action copy-once n’apparaîtront pas sur l’écran de l’éditeur de traduction. Toutefois, l’utilisateur peut modifier la valeur du terme personnalisé de la langue secondaire pour qu’elle soit différente de la langue par défaut en utilisant l’écran d’édition du message.
ignorer: cette action permet d’éliminer la copie du terme personnalisé dans la langue secondaire.

4. Types personnalisés

Les types de messages personnalisés que WPML doit traduire.

Vous pouvez ajouter l’attribut « display-as-translated » à la balise pour afficher les types de messages dans la langue courante si aucune traduction n’existe.

Vous pouvez ajouter l’attribut « automatic » à la balise pour exclure un type de message de la traduction automatique lorsque vous utilisez le mode » Translate Everything « . Veuillez noter que si vous utilisez cet attribut, l’ensemble de votre fichier de configuration de la langue ne fonctionnera que pour les versions 4.5.0 et supérieures de WPML.

5. Taxonomies personnalisées

Les taxonomies personnalisées que votre plugin pourrait utiliser et qui sont déjà enregistrées dans WP.

Remarque : les taxonomies qui n’ont pas besoin d’être traduites peuvent simplement être omises de cette liste.

Vous pouvez ajouter l’attribut « display-as-translated » à la balise pour afficher les taxonomies dans la langue par défaut si aucune traduction n’existe.

6. Blocs Gutenberg

Avec l’éditeur Gutenberg, vous construisez du contenu à l’aide de blocs.

Vous pouvez spécifier quelles parties de votre bloc Gutenberg doivent être traduites en ajoutant des paramètres à wpml-config.xml.

Xpath est utilisé pour définir les parties du texte qui doivent être traduites.

6.1 Enregistrer les blocs Gutenberg comme traduisibles

Disons que nous avons une image qui est affichée en utilisant le code suivant :

Nous voulons traduire les valeurs des attributs figcaption et alt de cette image.

Pour ce faire, le code suivant doit être inséré dans le fichier wpml-config.xml:

Veuillez garder à l’esprit que le type est core/image et non wp:image puisqu’il s’agit de la valeur renvoyée par l’API de bloc.

Vous pouvez spécifier quels champs du bloc Gutenberg sont des liens. WPML remplacera alors tous les liens par leurs traductions si elles sont disponibles.

6.2 Traduction des attributs des blocs

Voici un exemple de format pour la définition d’un bloc d’édition :

Vous pouvez utiliser l’élément clé de la même manière qu’avec les textes d’administration / la configurationwp_options. Cela signifie également que vous pouvez avoir des éléments clés à l’intérieur d’éléments clés parents.

Vous pouvez utiliser l’attribut label pour ajouter des étiquettes personnalisées facultatives qui s’affichent dans l’éditeur de traduction avancé à côté des éléments du bloc. Lorsque l’attribut label fait partie de la balise gutenberg-block, il sera utilisé comme label de secours pour les éléments du bloc qui n’ont pas de label spécifique défini.

Étiquette de repli dans l'éditeur de traduction avancé — Étiquette de repli dans l’éditeur de traduction avancé

L’attribut search-method peut avoir l’une des deux valeurs suivantes :

wildcards (par défaut)
regex.

Les caractères génériques peuvent être utilisés de la même manière que pour les textes d’administration. Cela signifie qu’un astérisque(*) peut être utilisé dans l’attribut name. Voici un exemple d’un bloc :

Nous pouvons définir la définition du bloc en utilisant un joker :

Cela nous permettra de traduire « Le titre » et « Le contenu » puisque ce sont les seuls attributs commençant par myp.

Le regex nous permet d’avoir une expression régulière dans l’attribut name. Cela peut être extrêmement utile pour les configurations complexes. Voici un exemple d’un bloc :

Nous pouvons définir la définition du bloc avec une expression régulière :

Cela nous permettra de traduire « Le titre » et « Le contenu » puisque ce sont les seuls attributs ne commençant pas par _.

Certains plugins de bloc enregistrent les données dans une chaîne JSON codée en URL à l’intérieur de l’attribut d’un bloc. L’attribut encodage permet de décoder la chaîne et d’enregistrer ses sous-clés pour la traduction.

Par exemple, le plugin LazyBlocks stocke le contenu des champs répétiteurs dans une chaîne JSON codée :

Vous pouvez enregistrer les sous-clés prénom et nom à l’aide de la configuration XML suivante :

6.3 Espace de nom de bloc

Vous pouvez disposer d’une configuration globale pour l’espace de noms des blocs.

Le nom du bloc n’est plus une partie obligatoire de la définition.

Si la configuration du bloc est la même pour tous les blocs d’un espace de nom, elle peut être écrite comme suit :

6.4 Conversion automatique des ID dans les blocs

Considérant le bloc suivant :

&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;/forme&gt;
&lt;/div&gt;
&lt;!-- /wp:foo/form --&gt;

Nous pouvons déclarer, en tant que post IDs, l’attribut block ids et la valeur de l’attribut de la balise HTML foo_form_post_ids comme ci-dessous :

&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;/clé&gt;
  &lt;xpath type="post-ids" sub-type="post"&gt;//*[@name="foo_form_post_ids"]/@value&lt;/xpath&gt;
&lt;/gutenberg-block&gt;

Et le bloc sera converti avec la plus haute priorité sur le filtre render_block_data comme ci-dessous :

&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;/forme&gt;
&lt;/div&gt;
&lt;!-- /wp:foo/formule →

Vous pouvez utiliser les attributs de configuration suivants :

type – peut être post-ids ou taxonomy-ids
sous-type (facultatif) : peut être l’entité spécifique du type si elle est déjà connue. Par exemple, product pour le type de message personnalisé Product. Si elle n’est pas définie, l’entité spécifique sera devinée.

7. Textes d’administration / wp_options

Chaînes qui font partie des options que les plugins ou les thèmes enregistrent dans la table wp_options.

Lorsque les thèmes et les plugins utilisent get_option, ils lisent les valeurs de la table wp_options. WPML peut filtrer ces appels et fournir la traduction des valeurs de ces options.

Cela fonctionne si l’enregistrement wp_option est une simple chaîne de caractères mais aussi lorsqu’il s’agit d’un tableau sérialisé.

Pour traduire une seule option, ajoutez une entrée de clé sous admin-texts. Pour traduire un tableau sérialisé, ajoutez plusieurs clés sous une clé, comme vous pouvez le voir dans my_plugin_options dans l’exemple ci-dessous.

Il est possible d’utiliser le joker * dans les sous-clés comme dans le cas suivant.

C’est égal à ce code :

Veuillez noter que le caractère générique * ne fonctionne PAS dans les clés parentales :

8. Configuration du sélecteur de langue

Active une configuration spécifique pour le sélecteur de langue intégré de WPML. Elle peut également être utilisée pour réinitialiser la configuration du sélecteur de langue si elle a été modifiée depuis le backend (à partir de ses valeurs initiales).

Pour voir les nouvelles modifications, veillez à cliquer sur le bouton Restaurer les valeurs par défaut en bas de la page WPML → Langues.

Il n’est pas nécessaire que toutes ces sections soient présentes dans le fichier de configuration, mais seulement celles qui s’appliquent à votre plugin ou à votre thème.

Utilisation du fichier de configuration de la langue WPML avec des thèmes enfants

Si vous utilisez un thème enfant, le fichier de configuration de la langue du thème parent prévaut sur celui du thème enfant. WPML fournit une page de configuration qui vous permet de remplacer facilement ces paramètres par des paramètres personnalisés.

Prenons un exemple où le fichier de configuration de la langue du thème parent définit le type de message personnalisé « Property » comme étant traduisible.

Le fichier de configuration de la langue parentale définit la propriété custom post type pour traduire

Si vous utilisez un thème enfant et que vous souhaitez définir le type de post personnalisé « Propriété » pour qu’il ne soit pas traduisible, accédez à la page WPML → Paramètres et cliquez sur l’onglet Configuration XML personnalisée. Utilisez l’éditeur pour définir le type de message personnalisé « Propriété » comme étant non traduisible. Il suffit de définir la valeur de l’attribut translate sur 0 au lieu de 1.

Remplacement des paramètres de configuration de la langue du thème parent

Les paramètres de l’onglet Configuration XML personnalisée sont prioritaires par rapport aux paramètres du fichier de configuration de la langue du thème parent.