Les fichiers de localisation sont des fichiers texte qui peuvent être ouverts et modifiés dans un éditeur de texte tel que Notepad ou TextEdit ou l'un des innombrables Outils d'édition de texte améliorés utilisés par les programmeurs. Ces fichiers suivent généralement le principe clé-valeur. Cela signifie qu'ils contiennent une liste d'extraits de texte (chaînes) qui sont associés à des identifiants uniques (clés). Chaque chaîne est donc une valeur d'une clé (cet exemple simple est le format des fichiers de localisation utilisés dans la programmation Java) :
-
clé1 = valeur1
-
key2 = value2
-
...
-
cléN = valeurN
Créer des fichiers de localisation
Les fichiers de localisation sont des fichiers texte brut avec une structure simple. Ils peuvent être créés manuellement mais sont généralement générés automatiquement par des utilitaires d'internationalisation ou des scripts disponibles pour différents environnements de développement. La création automatique de fichiers de localisation garantit la validité des structures de fichiers.
Pour créer un fichier de localisation, tous les éléments de texte affichables sont remplacés par des identifiants uniques dans les fichiers de code. Les chaînes de texte sont ensuite ajoutées au fichier de localisation avec leurs clés.
Utiliser des fichiers de localisation
Au lieu des chaînes de texte réelles, le code ne contient désormais que des clés. Lorsque le logiciel génère une vue pour l'utilisateur, ces clés sont utilisées pour rechercher les chaînes associées dans le fichier de localisation.
Si une application est configurée pour être utilisée en anglais et en espagnol, tout le texte anglais peut être conservé dans un fichier appelé English.txt et constitue l'emplacement de texte par défaut. Si un utilisateur ne sélectionne pas de langue, tout le texte sera extrait de ce fichier pour générer tout affichage. Si l'utilisateur sélectionne l'espagnol, le logiciel est redirigé vers Spanish.txt. De nombreuses langues peuvent être utilisées avec un système comme celui-ci.
L'avantage est que le choix de la langue pour l'affichage n'affecte pas le code. Si le logiciel doit afficher un bouton de connexion, il peut nécessiter la chaîne associée à la clé login_button et a seulement besoin de savoir dans quel fichier chercher pour récupérer la chaîne appropriée pour la langue donnée.
Gestion des chaînes
En tant que plateforme de traduction basée sur des clés, Phrase prend en charge de nombreux types de fichiers de ressources différents. Après le téléchargement des fichiers, les clés et leurs valeurs de chaîne associées sont extraites. Les clés et les chaînes sont ensuite présentées au traducteur dans un format standardisé. Les traducteurs se concentrent sur leur tâche sans avoir à se soucier du format exact du fichier de localisation. Ils peuvent inspecter les clés, car la clé elle-même peut fournir un contexte crucial et les guider vers des choix de mots corrects.
Lorsque toutes les chaînes sont traduites, les fichiers sont téléchargés. Au cours du processus, le format de fichier de localisation nécessaire est créé pour correspondre au fichier source original.
Formats de fichier de ressources
Quatre grands types de ressources sont pris en charge ; ils sont tous essentiellement basés sur du texte et peuvent être ouverts et inspectés dans un éditeur de texte.
Feuilles de calcul
Les fichiers .XLSX et .CSV sont pris en charge. Ces formats sont équivalents à des fins de localisation et contiennent des lignes de paires clé-valeur. Les clés se trouvent sur une ligne, tandis que les valeurs correspondantes se trouvent sur une ligne adjacente. La colonne exacte utilisée pour chaque objectif dépend de l'application, et un localisateur doit configurer Phrase pour interpréter correctement les colonnes. Les fichiers .CSV Zendesk ont une structure fixe, ce type de fichier ne nécessite donc aucun ajustement supplémentaire :
"Titre","Langue par défaut","Texte par défaut","Texte anglais","Statut de la variante" "simple_key","German","Einfacher Schlüssel.","Simple key.","Current"
XML
XML est un format qui offre des méta-informations sous la forme de <balises>. La structure de balise est utilisée pour déterminer où se trouvent les clés et leurs valeurs correspondantes, comme le montre ici un fichier XML Android :
<string name="simple_key">Just a key with a message.</string>
Deux formats de traduction XML standard sont .TMX et .XLIFF. Ceux-ci ne contiennent pas seulement des clés et des valeurs dans une langue, mais associent également des paires de valeurs d'une langue source avec des valeurs correspondantes d'une langue cible. De tels fichiers sont généralement bilingues, comme le montre cette unité de traduction dans un fichier Xliff Symfony :
<trans-unit id="simple_key" resname="simple_key"> <source xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source> <target xml:lang="en-GB">Just a simple key with a simple message.</target> </trans-unit>
Les programmes QT utilisent des fichiers de ressources avec une structure très similaire à ces formats standardisés, mais pour des raisons historiques, ils ont une disposition différente.
Listes de clés-valeurs simples
Il existe des fichiers de ressources qui contiennent uniquement des listes simples de clés et de valeurs, comme le montre cet extrait d'un YAML Ruby on Rails :
simple_key: Just a simple key with a simple message.
De nombreux langages de programmation ou plateformes différents utilisent de tels formats avec des différences de disposition Mineure.
Comme il s'agit de fichiers monolingues, un programme de localisation doit maintenir des versions parallèles de ces fichiers - une pour la langue source et d'autres pour les langues cible.
Gettext produit des fichiers clé-valeur contenant des informations supplémentaires, telles que des commentaires descriptifs ou des variantes plurielles :
# Ceci est l'incroyable description pour cette clé ! msgid "key_with_description" msgid_plural "" msgstr[0] "Découvrez-le !" Cette clé a une description ! (Au moins dans certains formats)" msgstr[1] "Découvrez-le !" Cette clé a %s descriptions ! (Au moins dans certains formats)"
Il existe des formats concurrents avec des fonctionnalités similaires et des mises en page qui varient de manière relativement Mineure.
Tableaux associatifs
Alors que d'autres formats nécessitent un code Personnalisé (analyseurs) pour les lire, certains formats sont plus faciles pour les développeurs et les localisateurs. Les formats basés sur .JSON (JavaScript) et les tableaux .PHP peuvent être lus et mappés directement dans des structures de code courantes (tableaux) faciles à manipuler. Les tableaux peuvent être complexes et différentes applications génèrent des structures de tableau Personnalisé.
Par exemple, go-i18n JSON fait référence aux clés en tant qu'Identifiant :
{
"id": "simple_key",
"translation": "simple clé, simple message, tellement simple."
},
Angular utilise les clés elles-mêmes comme clé dans ses tableaux :
"simple_key": "I am a simple key with a simple message.".
Comme il existe ces différences Mineure mais cruciales, les structures de tableau .JSON et .PHP largement utilisées sont prises en charge.