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 nombreux 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 de morceaux 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éation de fichiers de localisation
Les fichiers de localisation sont des fichiers en 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 ou des scripts d'internationalisation disponibles pour différents environnements de développement. La création automatique de fichiers de localisation garantit que les structures de fichiers sont valides.
Pour créer un fichier de localisation, tous les morceaux 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 identifiants.
Utilisation des fichiers de localisation
Au lieu des chaînes de texte réelles, le code contient maintenant uniquement 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 en anglais peut être conservé dans un fichier appelé English.txt et est l'emplacement de texte par défaut. Si un utilisateur ne sélectionne pas de langue, tout le texte sera tiré 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 n'a besoin de savoir que 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 que les fichiers sont téléchargés, 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. Dans le processus, les formats de fichiers de localisation nécessaires sont créés pour correspondre au fichier source original.
Formats de fichiers de ressources {2<file formats
Quatre grands types de ressources sont pris en charge et sont tous essentiellement basés sur du texte et peuvent être ouverts et inspectés dans un éditeur de texte.
Tableurs
.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 dans une ligne, tandis que les valeurs correspondantes se trouvent dans une ligne adjacente. Quelle colonne exacte est utilisée pour quel but dépend de l'application, et un localisateur doit configurer Phrase pour interpréter les colonnes correctement. Les fichiers .CSV de ZenDesk ont une structure fixe, donc ce type de fichier ne nécessite pas d'ajustements supplémentaires :
"Titre","Langue par défaut","Texte par défaut","Texte en anglais","Statut de variante" "simple_key","German","Einfacher Schlüssel.","Simple key.","Current"
XML
XML est un format qui offre des méta-informations sous forme de <tags>. La structure des balises 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">Juste une clé avec un message.</string>
Deux formats de traduction XML standard sont .TMX et .XLIFF. Ceci ne contient pas seulement des clés et des valeurs dans une langue, mais associe é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 Symfony Xliff :
<trans-unit id="simple_key" resname="simple_key"> <source xml:lang="fr-FR">Juste une clé simple avec un message simple.</source <target xml:lang="en-GB">Juste une clé simple avec un message simple.</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 mise en page différente.
Listes de clés-valeurs simples
Il existe des fichiers de ressources qui contiennent juste des listes simples de clés et de valeurs, comme le montre cet extrait d'un YAML Ruby on Rails :
simple_key: Juste une clé simple avec un message simple.
De nombreux langages de programmation ou plateformes utilisent de tels formats avec des différences mineures de mise en page.
Puisque ce sont des fichiers monolingues, un programme de localisation doit maintenir des versions parallèles de tels fichiers - une pour la langue source et d'autres pour les langues cibles.
Gettext produit des fichiers clé-valeur contenant des informations supplémentaires, telles que des commentaires descriptifs ou des variantes plurielles :
# Ceci est la description incroyable pour cette clé ! msgid "key_with_description" msgid_plural "" msgstr[0] "Vérifiez-le ! Cette clé a une description ! (Au moins dans certains formats)" msgstr[1] "Vérifiez-le ! Cette clé a %s descriptions ! (Au moins dans certains formats)"
Il existe des formats concurrents avec des fonctionnalités et des mises en page similaires qui varient de manière relativement mineure.
Tableaux associatifs
Alors que d'autres formats nécessitent un code personnalisé (parseurs) pour les lire, certains formats sont plus faciles pour les développeurs et les localisateurs. Les formats basés sur .JSON (JavaScript) et .PHP peuvent être lus et mappés directement dans des structures de code communes (tableaux) qui sont faciles à manipuler. Les tableaux peuvent être complexes et différentes applications génèrent des structures de tableaux personnalisées.
Par exemple, go-i18n JSON fait référence aux clés comme id :
{
"id": "simple_key",
"translation": "clé simple, message simple, tellement simple."
},
Angular utilise les clés elles-mêmes comme clés dans ses tableaux :
"simple_key": "Je suis une clé simple avec un message simple.".
Puisqu'il existe ces différences mineures mais cruciales, les structures de tableaux .JSON et .PHP largement utilisées sont prises en charge.