Comment créer une application multilingue : une démo avec PHP et Gettext

Que vous construisiez un site Web ou une application Web à part entière, le rendre accessible à un public plus large nécessite souvent qu'il soit disponible dans différentes langues et régions.

Les différences fondamentales entre la plupart des langues humaines rendent cela tout sauf facile. Les différences dans les règles de grammaire, les nuances linguistiques, les formats de date, etc. se combinent pour faire de la localisation un défi unique et formidable.

Considérez cet exemple simple.

Les règles de pluralisation en anglais sont assez simples : vous pouvez avoir une forme singulière d'un mot ou une forme plurielle d'un mot.

Dans d'autres langues, cependant - comme les langues slaves - il existe deux formes plurielles en plus du singulier. Vous pouvez même trouver des langues avec un total de quatre, cinq ou six formes plurielles, comme le slovène, l'irlandais ou l'arabe.

La façon dont votre code est organisé et la façon dont vos composants et votre interface sont conçus jouent un rôle important dans la détermination de la facilité avec laquelle vous pouvez localiser votre application.

L'internationalisation (i18n) de votre base de code permet de s'assurer qu'elle peut être adaptée à différentes langues ou régions avec une relative facilité. L'internationalisation n'est généralement effectuée qu'une seule fois, de préférence au début du projet pour éviter d'avoir à modifier considérablement le code source par la suite.

Une fois que votre base de code a été internationalisée, la localisation (l10n) consiste à traduire le contenu de votre application dans une langue/locale spécifique.

La localisation doit être effectuée chaque fois qu'une nouvelle langue ou région doit être prise en charge. De plus, chaque fois qu'une partie de l'interface (contenant du texte) est mise à jour, un nouveau contenu devient disponible - qui doit ensuite être localisé (c'est-à-dire traduit) dans tous les paramètres régionaux pris en charge.

Dans cet article, nous allons apprendre à internationaliser et localiser des logiciels écrits en PHP. Nous passerons en revue les différentes options de mise en œuvre et les différents outils mis à notre disposition pour faciliter le processus.

Outils pour l'internationalisation

Le moyen le plus simple d'internationaliser un logiciel PHP consiste à utiliser des fichiers de tableau. Les tableaux seront remplis de chaînes traduites, qui pourront ensuite être recherchées à partir des modèles :

 <h1><?=$TRANS['title_about_page']?></h1>

Ce n'est cependant pas une méthode recommandée pour les projets sérieux, car cela posera certainement des problèmes de maintenance plus tard. Certains problèmes peuvent même apparaître au tout début, comme le manque de prise en charge de l'interpolation variable ou de la pluralisation des noms, etc.

L'un des outils les plus classiques (souvent pris comme référence pour i18n et l10n) est un outil Unix appelé Gettext.

Bien que datant de 1995, il s'agit toujours d'un outil complet de traduction de logiciels qui est également facile à utiliser. Bien qu'il soit assez facile de démarrer, il dispose toujours de puissants outils de support.

Gettext est ce que nous allons utiliser dans cet article. Nous présenterons une excellente application graphique qui peut être utilisée pour mettre à jour facilement vos fichiers source l10n, évitant ainsi d'avoir à gérer la ligne de commande.

Des bibliothèques pour faciliter les choses

Il existe d'importants frameworks et bibliothèques Web PHP qui prennent en charge Gettext et d'autres implémentations d'i18n. Certains sont plus faciles à installer que d'autres, ou intègrent des fonctionnalités supplémentaires ou prennent en charge différents formats de fichiers i18n. Bien que dans ce document, nous nous concentrions sur les outils fournis avec le noyau PHP, voici une liste de quelques autres qui méritent d'être mentionnés :

• oscarotero/Gettext : prise en charge de Gettext avec une interface orientée objet ; inclut des fonctions d'assistance améliorées, de puissants extracteurs pour plusieurs formats de fichiers (certains d'entre eux ne sont pas pris en charge nativement par la commande gettext ). Peut également exporter vers des formats autres que les fichiers .mo/.po, ce qui peut être utile si vous devez intégrer vos fichiers de traduction dans d'autres parties du système, comme une interface JavaScript.

• symfony/translation : prend en charge de nombreux formats différents, mais recommande d'utiliser des XLIFF verbeux. N'inclut pas de fonctions d'assistance ni d'extracteur intégré, mais prend en charge les espaces réservés utilisant strtr() en interne.

• zend/i18n : prend en charge les fichiers tableau et INI, ou les formats Gettext. Implémente une couche de mise en cache pour éviter d'avoir à lire le système de fichiers à chaque fois. Comprend également des aides à la vue, des filtres d'entrée et des validateurs compatibles avec les paramètres régionaux. Cependant, il n'a pas d'extracteur de message.

D'autres frameworks incluent également des modules i18n, mais ceux-ci ne sont pas disponibles en dehors de leurs bases de code :

• Laravel : prend en charge les fichiers de tableau de base ; n'a pas d'extracteur automatique mais inclut un assistant @lang pour les fichiers modèles.

• Yii : prend en charge la traduction basée sur les tableaux, Gettext et la base de données, et inclut un extracteur de messages. Soutenu par l'extension Intl , disponible depuis PHP 5.3, et basé sur le projet ICU. Cela permet à Yii d'exécuter des remplacements puissants, comme l'orthographe des nombres, le formatage des dates, des heures, des intervalles, des devises et des ordinaux.

Si vous décidez d'opter pour l'une des bibliothèques qui ne fournissent pas d'extracteurs, vous pouvez utiliser les formats Gettext, afin que vous puissiez utiliser la chaîne d'outils Gettext originale (y compris Poedit) comme décrit dans le reste du chapitre.

Installer Gettext

Vous devrez peut-être installer Gettext et la bibliothèque PHP associée en utilisant votre gestionnaire de packages, comme apt-get ou yum. Une fois installé, activez-le en ajoutant extension=gettext.so (Linux/Unix) ou extension=php_gettext.dll (Windows) à votre fichier php.ini .

Ici, nous utiliserons également Poedit pour créer des fichiers de traduction. Vous le trouverez probablement dans le gestionnaire de paquets de votre système ; il est disponible pour Unix, Mac et Windows et peut également être téléchargé gratuitement sur son site Web.

Types de fichiers Gettext

Il existe trois types de fichiers que vous traitez généralement lorsque vous travaillez avec Gettext.

Les principaux sont les fichiers PO (Portable Object) et MO (Machine Object), le premier étant une liste d'"objets traduits" lisibles et le second étant le binaire correspondant (à interpréter par Gettext lors de la localisation). Il existe également un fichier POT (modèle PO), qui contient simplement toutes les clés existantes de vos fichiers source et peut être utilisé comme guide pour générer et mettre à jour tous les fichiers PO.

Les fichiers modèles ne sont pas obligatoires ; selon l'outil que vous utilisez pour faire l10n, vous serez très bien avec seulement les fichiers PO/MO. Vous aurez une paire de fichiers PO/MO par langue et région, mais un seul POT par domaine.

Séparer les domaines

Dans certains cas, dans les grands projets, vous devrez peut-être séparer les traductions lorsque les mêmes mots ont une signification différente dans différents contextes.

Dans ces cas, vous devrez les diviser en différents "domaines", qui sont essentiellement des groupes nommés de fichiers POT/PO/MO, où le nom de fichier est ledit domaine de traduction .

Les projets de petite et moyenne taille utilisent généralement, pour des raisons de simplicité, un seul domaine ; son nom est arbitraire, mais nous utiliserons "main" pour nos exemples de code.

Dans les projets Symfony, par exemple, les domaines sont utilisés pour séparer la traduction des messages de validation.

Code régional

Une locale est simplement un code qui identifie une version d'une langue. Il est défini selon les spécifications ISO 639-1 et ISO 3166-1 alpha-2 : deux lettres minuscules pour la langue, éventuellement suivies d'un trait de soulignement et de deux lettres majuscules identifiant le pays ou le code régional.

Pour les langues rares, trois lettres sont utilisées.

Pour certains locuteurs, la partie country peut sembler redondante. En fait, certaines langues ont des dialectes dans différents pays, comme l'allemand autrichien (de_AT) ou le portugais brésilien (pt_BR). La deuxième partie est utilisée pour faire la distinction entre ces dialectes - lorsqu'elle n'est pas présente, elle est considérée comme une version "générique" ou "hybride" de la langue.

Structure du répertoire

Pour utiliser Gettext, nous devrons adhérer à une structure spécifique de dossiers.

Tout d'abord, vous devrez sélectionner une racine arbitraire pour vos fichiers l10n dans votre référentiel source. À l'intérieur, vous aurez un dossier pour chaque paramètre régional nécessaire et un dossier fixe "LC_MESSAGES" qui contiendra toutes vos paires PO/MO.

Formes du pluriel

Comme nous l'avons dit dans l'introduction, différentes langues peuvent avoir des règles de pluralisation différentes. Cependant, Gettext nous évite ce problème.

Lors de la création d'un nouveau fichier .po, vous devrez déclarer les règles de pluralisation pour cette langue, et les pièces traduites sensibles au pluriel auront une forme différente pour chacune de ces règles.

Lors de l'appel de Gettext dans le code, vous devrez spécifier un nombre lié à la phrase (par exemple, pour la phrase "Vous avez n messages.", vous devrez spécifier la valeur de n), et cela déterminera la forme correcte à utiliser - même en utilisant la substitution de chaîne si nécessaire.

Les règles plurielles sont composées du nombre de règles nécessaires avec un test booléen pour chaque règle (le test pour au plus une règle peut être omis). Par exemple:

• Japonais : nplurals=1; plural=0; nplurals=1; plural=0; - une règle : il n'y a pas de formes plurielles

• Anglais : nplurals=2; plural=(n != 1); nplurals=2; plural=(n != 1); - deux règles : utiliser le pluriel uniquement lorsque n n'est pas 1, sinon utiliser le singulier.

• Portugais brésilien : nplurals=2; plural=(n > 1); nplurals=2; plural=(n > 1); - deux règles, utiliser le pluriel uniquement lorsque n est supérieur à 1, sinon utiliser le singulier.

Pour une explication plus approfondie, un didacticiel LingoHub informatif est disponible en ligne.

Gettext déterminera la règle à utiliser en fonction du nombre fourni et utilisera la version localisée correcte de la chaîne. Pour les chaînes où la pluralisation doit être gérée, vous devrez inclure dans le fichier .po une phrase différente pour chaque règle plurielle définie.

Exemple de mise en œuvre

Après toute cette théorie, passons à la pratique. Voici un extrait d'un fichier .po (ne vous souciez pas encore trop de la syntaxe, mais ayez plutôt une idée du contenu global) :

 msgid "" msgstr "" "Language: pt_BR\n" "Content-Type: text/plain; charset=UTF-8\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" msgid "We're now translating some strings" msgstr "Nos estamos traduzindo algumas strings agora" msgid "Hello %1$s! Your last visit was on %2$s" msgstr "Ola %1$s! Sua ultima visita foi em %2$s" msgid "Only one unread message" msgid_plural "%d unread messages" msgstr[0] "So uma mensagem nao lida" msgstr[1] "%d mensagens nao lidas"

La première section fonctionne comme un en-tête, avec msgid et msgstr vides.

Il décrit l'encodage du fichier, les formes plurielles et quelques autres choses. La deuxième section traduit une chaîne simple de l'anglais vers le portugais brésilien, et la troisième fait de même, mais exploite le remplacement de chaîne de sprintf , permettant à la traduction de contenir le nom d'utilisateur et la date de visite.

La dernière section est un exemple de formes de pluralisation, affichant la version singulière et plurielle sous la forme msgid en anglais et leurs traductions correspondantes sous la forme msgstr 0 et 1 (suivant le nombre donné par la règle du pluriel).

Là, le remplacement de chaîne est également utilisé, de sorte que le nombre peut être vu directement dans la phrase, en utilisant %d . Les formes plurielles ont toujours deux msgid (singulier et pluriel), il est donc conseillé de ne pas utiliser une langue complexe comme source de traduction.

Clés de localisation

Comme vous l'avez peut-être remarqué, nous utilisons la phrase anglaise réelle comme ID source. Ce msgid est le même utilisé dans tous vos fichiers .po, ce qui signifie que les autres langues auront le même format et les mêmes champs msgid mais des lignes msgstr traduites.

En parlant de clés de traduction, il existe ici deux approches « philosophiques » standard :

1. msgid comme une vraie phrase

Les principaux avantages de cette approche sont :

• S'il y a des parties du logiciel non traduites dans une langue donnée, la clé affichée conservera toujours une certaine signification. Par exemple, si vous savez comment traduire de l'anglais vers l'espagnol mais que vous avez besoin d'aide pour traduire vers le français, vous pouvez publier la nouvelle page avec des phrases françaises manquantes, et des parties du site Web seront affichées en anglais à la place.

• Il est beaucoup plus facile pour le traducteur de comprendre ce qui se passe et de faire une traduction correcte basée sur le msgid .

• Il vous donne l10n "gratuit" pour une langue - la langue source.

D'un autre côté, le principal inconvénient est que, si vous devez modifier le texte réel, vous devez remplacer le même msgid dans plusieurs fichiers de langue.

2. msgid en tant que clé structurée unique

Cela décrirait le rôle de la phrase dans l'application de manière structurée, y compris le modèle ou la partie où se trouve la chaîne au lieu de son contenu.

C'est un excellent moyen d'organiser le code, en séparant le contenu du texte de la logique du modèle. Cependant, cela pourrait poser des problèmes au traducteur qui manquerait le contexte.

Un fichier de langue source serait nécessaire comme base pour d'autres traductions. Par exemple, le développeur aurait idéalement un fichier « en.po », que les traducteurs liraient pour comprendre ce qu'il faut écrire dans « fr.po ».

Les traductions manquantes afficheraient des touches sans signification à l'écran ("top_menu.welcome" au lieu de "Hello there, User!" sur ladite page française non traduite).

C'est bien car cela forcerait la traduction à être complète avant la publication - mais c'est mauvais car les problèmes de traduction seraient vraiment horribles dans l'interface. Certaines bibliothèques, cependant, incluent une option pour spécifier une langue donnée comme "de secours", ayant un comportement similaire à l'autre approche.

Le manuel Gettext privilégie la première approche car, en général, c'est plus facile pour les traducteurs et les utilisateurs en cas de problème. C'est également l'approche que nous utiliserons ici.

Il convient de noter, cependant, que la documentation de Symfony favorise la traduction basée sur des mots-clés, pour permettre des modifications indépendantes de toutes les traductions sans affecter également les modèles.

Utilisation quotidienne

Dans une application courante, vous utiliseriez certaines fonctions Gettext lors de l'écriture de texte statique dans vos pages.

Ces phrases apparaîtraient alors dans des fichiers .po, seraient traduites, compilées dans des fichiers .mo, puis utilisées par Gettext lors du rendu de l'interface réelle. Compte tenu de cela, relions ce dont nous avons discuté jusqu'à présent dans un exemple étape par étape :

1. Un exemple de fichier de modèle, comprenant différents appels gettext

 <?php include 'i18n_setup.php' ?> <div> <h1><?=sprintf(gettext('Welcome, %s!'), $name)?></h1> <!-- code indented this way only for legibility → <?php if ($unread): ?> <h2> <?=sprintf( ngettext('Only one unread message', '%d unread messages', $unread), $unread )?> </h2> <?php endif ?> </div> <h1><?=gettext('Introduction')?></h1> <p><?=gettext('We\'re now translating some strings')?></p>

• gettext() traduit simplement un msgid en son msgstr correspondant pour une langue donnée. Il y a aussi la fonction abrégée _() qui fonctionne de la même manière

• ngettext() fait la même chose mais avec des règles plurielles

• Il y a aussi dgettext() et dngettext() , qui vous permettent de remplacer le domaine pour un seul appel (plus sur la configuration du domaine dans l'exemple suivant)

2. Un exemple de fichier de configuration (i18n_setup.php tel qu'utilisé ci-dessus), en sélectionnant les paramètres régionaux corrects et en configurant Gettext

L'utilisation de Gettext implique un peu de code passe-partout, mais il s'agit principalement de configurer le répertoire des locales et de choisir les paramètres appropriés (une locale et un domaine).

 <?php /** * Verifies if the given $locale is supported in the project * @param string $locale * @return bool */ function valid($locale) { return in_array($locale, ['en_US', 'en', 'pt_BR', 'pt', 'es_ES', 'es'); } //setting the source/default locale, for informational purposes $lang = 'en_US'; if (isset($_GET['lang']) && valid($_GET['lang'])) { // the locale can be changed through the query-string $lang = $_GET['lang']; //you should sanitize this! setcookie('lang', $lang); //it's stored in a cookie so it can be reused } elseif (isset($_COOKIE['lang']) && valid($_COOKIE['lang'])) { // if the cookie is present instead, let's just keep it $lang = $_COOKIE['lang']; //you should sanitize this! } elseif (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) { // default: look for the languages the browser says the user accepts $langs = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']); array_walk($langs, function (&$lang) { $lang = strtr(strtok($lang, ';'), ['-' => '_']); }); foreach ($langs as $browser_lang) { if (valid($browser_lang)) { $lang = $browser_lang; break; } } } // here we define the global system locale given the found language putenv("LANG=$lang"); // this might be useful for date functions (LC_TIME) or money formatting (LC_MONETARY), for instance setlocale(LC_ALL, $lang); // this will make Gettext look for ../locales/<lang>/LC_MESSAGES/main.mo bindtextdomain('main', '../locales'); // indicates in what encoding the file should be read bind_textdomain_codeset('main', 'UTF-8'); // if your application has additional domains, as cited before, you should bind them here as well bindtextdomain('forum', '../locales'); bind_textdomain_codeset('forum', 'UTF-8'); // here we indicate the default domain the gettext() calls will respond to textdomain('main'); // this would look for the string in forum.mo instead of main.mo // echo dgettext('forum', 'Welcome back!'); ?>

3. Préparation de la traduction pour la première exécution

L'un des grands avantages de Gettext par rapport aux packages de framework i18n personnalisés est son format de fichier étendu et puissant.

Peut-être pensez-vous "Oh mec, c'est assez difficile à comprendre et à éditer à la main, un simple tableau serait plus facile!" Ne vous méprenez pas, des applications comme Poedit sont là pour vous aider - beaucoup. Vous pouvez obtenir le programme sur leur site Web, il est gratuit et disponible pour toutes les plateformes. C'est un outil assez facile à utiliser et très puissant en même temps - en utilisant toutes les fonctionnalités dont Gettext dispose. Nous allons travailler ici avec la dernière version, Poedit 1.8.

Lors de la première exécution, vous devez sélectionner « Fichier > Nouveau… » dans le menu. On vous demandera la langue; sélectionnez/filtrez la langue dans laquelle vous souhaitez traduire, ou utilisez le format que nous avons mentionné précédemment, tel que en_US ou pt_BR .

Maintenant, enregistrez le fichier - en utilisant cette structure de répertoires que nous avons également mentionnée. Ensuite, vous devez cliquer sur "Extraire des sources", et ici vous configurerez divers paramètres pour les tâches d'extraction et de traduction. Vous pourrez les retrouver plus tard via « Catalogue > Propriétés » :

• Chemins source : incluez tous les dossiers du projet où gettext() (et ses frères et sœurs) sont appelés - il s'agit généralement de votre ou vos dossiers de modèles/vues. C'est le seul paramètre obligatoire.

• Propriétés de traduction :

  • Nom et version du projet, équipe et adresse e-mail de l'équipe : informations utiles qui figurent dans l'en-tête du fichier .po.
  • Formes plurielles : Ce sont les règles que nous avons mentionnées précédemment. Vous pouvez le laisser avec l'option par défaut la plupart du temps, car Poedit inclut déjà une base de données pratique de règles plurielles pour de nombreuses langues.
  • Jeux de caractères : UTF-8, de préférence.
  • Jeu de caractères du code source : le jeu de caractères utilisé par votre base de code - probablement UTF-8 également, n'est-ce pas ?

• Mots-clés source : le logiciel sous-jacent sait à quoi ressemblent gettext() et les appels de fonction similaires dans plusieurs langages de programmation, mais vous pouvez tout aussi bien créer vos propres fonctions de traduction. Ce sera ici que vous ajouterez ces autres méthodes. Cela sera discuté plus tard dans la section "Conseils".

Après avoir défini ces propriétés, Poedit effectuera une analyse de vos fichiers source pour trouver tous les appels de localisation. Après chaque analyse, Poedit affichera un résumé de ce qui a été trouvé et de ce qui a été supprimé des fichiers source. Les nouvelles entrées seront vides dans la table de traduction, vous permettant d'entrer les versions localisées de ces chaînes. Enregistrez-le et un fichier .mo sera (re)compilé dans le même dossier et, hop !, votre projet est internationalisé !

Poedit peut également suggérer des traductions courantes à partir du Web et de fichiers précédents. C'est pratique, vous n'avez qu'à vérifier s'ils ont du sens et les accepter. Si vous n'êtes pas sûr d'une traduction, vous pouvez la marquer comme floue et elle s'affichera en jaune. Les entrées bleues sont celles qui n'ont pas de traduction.

4. Traduction de chaînes

Comme vous l'avez peut-être remarqué, il existe deux principaux types de chaînes localisées : les chaînes simples et celles au pluriel.

Les plus simples n'ont que deux cases : source et chaîne localisée. La chaîne source ne peut pas être modifiée, car Gettext/Poedit n'inclut pas la possibilité de modifier vos fichiers source ; vous devrez plutôt changer la source elle-même et réanalyser les fichiers. ( Astuce : si vous cliquez avec le bouton droit sur une ligne de traduction, un indice s'affichera avec les fichiers source et les lignes où cette chaîne est utilisée.)

Les chaînes de forme plurielle incluent deux cases pour afficher les deux chaînes source et des onglets pour que vous puissiez configurer les différentes formes finales.

Exemple de chaîne au pluriel sur Poedit, montrant un onglet de traduction pour chacune.

Chaque fois que vous modifiez vos fichiers de code source et que vous devez mettre à jour les traductions, appuyez simplement sur Actualiser et Poedit analysera à nouveau le code, supprimant les entrées inexistantes, fusionnant celles qui ont changé et en ajoutant de nouvelles.

Poedit peut aussi essayer de deviner certaines traductions, basées sur d'autres que vous avez faites. Ces suppositions et les entrées modifiées recevront un marqueur "Fuzzy", indiquant qu'elles doivent être révisées, affiché en jaune dans la liste.

C'est également utile si vous avez une équipe de traduction et que quelqu'un essaie d'écrire quelque chose dont il n'est pas sûr : marquez-le simplement comme flou et quelqu'un d'autre le révisera plus tard.

Enfin, il est conseillé de laisser "Affichage > Entrées non traduites en premier" coché, car cela vous évitera d'oublier des entrées. À partir de ce menu, vous pouvez également ouvrir des parties de l'interface utilisateur qui vous permettent de laisser des informations contextuelles aux traducteurs si nécessaire.

Conseils & Astuces

Les serveurs Web peuvent finir par mettre en cache vos fichiers .mo.

Si vous exécutez PHP en tant que module sur Apache (mod_php), vous pourriez rencontrer des problèmes avec le fichier .mo mis en cache. Cela se produit la première fois qu'il est lu, puis, pour le mettre à jour, vous devrez peut-être redémarrer le serveur.

Sur Nginx et PHP5, il ne faut généralement que quelques actualisations de page pour actualiser le cache de traduction, et sur PHP7, cela est rarement nécessaire.

Les bibliothèques fournissent des fonctions d'assistance pour garder le code de localisation court.

Comme le préfèrent de nombreuses personnes, il est plus facile d'utiliser _() au lieu de gettext() . De nombreuses bibliothèques i18n personnalisées à partir de frameworks utilisent également quelque chose de similaire à t() , pour raccourcir le code traduit. Cependant, c'est la seule fonction qui arbore un raccourci.

Vous voudrez peut-être en ajouter d'autres dans votre projet, tels que __() ou _n() pour ngettext() , ou peut-être un _r() fantaisiste qui rejoindrait les appels gettext() et sprintf() . D'autres bibliothèques, telles que Gettext d'Oscarotero, fournissent également des fonctions d'assistance comme celles-ci.

Dans ces cas, vous devrez indiquer à l'utilitaire Gettext comment extraire les chaînes de ces nouvelles fonctions. N'ayez pas peur, c'est très facile. C'est juste un champ dans le fichier .po ou un écran Paramètres dans Poedit (dans l'éditeur, cette option se trouve dans « Catalogue > Propriétés > Mots-clés sources »).

N'oubliez pas : Gettext connaît déjà les fonctions par défaut pour de nombreuses langues, alors ne vous inquiétez pas si cette liste semble vide. Vous devez inclure dans cette liste les spécifications des nouvelles fonctions, en suivant ce format spécifique :

• Si vous créez quelque chose comme t() , qui renvoie simplement la traduction d'une chaîne, vous pouvez le spécifier comme t . Gettext saura que le seul argument de la fonction est la chaîne à traduire ;

• Si la fonction a plus d'un argument, vous pouvez spécifier dans lequel se trouve la première chaîne et, si nécessaire, la forme plurielle également. Par exemple, si notre signature de fonction est __('one user', '%d users', $number) , la spécification serait __:1,2 , ce qui signifie que la première forme est le premier argument, et la seconde forme est le deuxième argumentation. Si votre nombre est plutôt le premier argument, la spécification serait __:2,3 , indiquant que la première forme est le deuxième argument, et ainsi de suite.

Après avoir inclus ces nouvelles règles dans le fichier .po, une nouvelle analyse apportera vos nouvelles chaînes aussi facilement qu'auparavant.

Rendez votre application PHP multilingue avec Gettext

Gettext est un outil très puissant pour internationaliser votre projet PHP. Au-delà de sa flexibilité qui permet la prise en charge d'un grand nombre de langages humains, sa prise en charge de plus de 20 langages de programmation vous permet de transférer facilement vos connaissances sur son utilisation avec PHP vers d'autres langages comme Python, Java ou C#.

De plus, Poedit peut aider à faciliter le chemin entre le code et les chaînes traduites, rendant le processus plus simple et plus facile à suivre. Il peut également rationaliser les efforts de traduction partagés grâce à son intégration Crowdin.

Dans la mesure du possible, envisagez d'autres langues que vos utilisateurs pourraient parler. Ceci est particulièrement important pour les projets non anglais : vous pouvez augmenter votre accès utilisateur si vous le publiez en anglais ainsi que dans votre langue maternelle.

Bien sûr, tous les projets n'ont pas besoin d'internationalisation, mais il est beaucoup plus facile de démarrer i18n au début d'un projet, même s'il n'est pas nécessaire au départ, que de le faire plus tard si cela devenait une exigence par la suite. Et, avec des outils comme Gettext et Poedit, c'est plus facile que jamais.