Fichiers de localisation (Strings)

Les fichiers de localisation sont des fichiers de texte qui peuvent être ouverts et modifiés dans un éditeur de texte tel que Notepad ou TextEdit ou l'un des myriades Outils améliorés d'édition de texte 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 (Strings) qui sont associés à des identifiants uniques (clés). Chaque chaîne est ainsi une valeur d'une clé (Cet exemple simple est le format des fichiers de localisation utilisés dans la programmation Java.):

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 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 des fichiers.

Pour créer un fichier de localisation, tous les morceaux de texte affichable sont remplacés par des identifiants uniques dans les fichiers de code. Les text Strings sont ensuite ajoutées au fichier de localisation avec leurs identifiants.

Utiliser les fichiers de localisation

Au lieu des Strings textuelles proprement dites, le code ne contient plus que des clés. Lorsque le logiciel génère une vue pour l'utilisateur, ces clés sont utilisées pour chercher les Strings 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 du 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 un quelconque 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 login, il peut nécessiter la chaîne associée au bouton login_ clé et doit seulement 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 clé, Phrase prend en charge de nombreux types de fichiers de ressources différents. Après avoir des fichiers sont téléversés, les clés et leurs valeurs de chaîne associées sont extraites. Les clés et Strings sont ensuite présentées au traducteur dans un format normalisé. 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 pour corriger les choix de mots.

Lorsque toutes Strings sont traduites, des fichiers sont téléchargés. Dans le processus, le format de fichier de localisation nécessaire est créé en correspondance avec le fichier source d'origine.

Formats de fichiers de ressource

Quatre grands types de ressources sont prises en charge. Elles sont toutes essentiellement basées sur du texte et peuvent être ouvertes et inspectées dans un éditeur de texte.

Tableurs

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 sont sur une ligne, tandis que les valeurs correspondantes sont sur une ligne adjacente. Quelle colonne exacte est utilisée dans quel but 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 pas d’autres ajustements :

"Title","Default language","Default text","English text","Variant status"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

Le format XML est un format qui propose 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:

 <chaîne name="simple_clé">Juste une clé avec un message.</chaîne>

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 à des valeurs correspondantes d'une langue cible. Ces 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="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source
<cible xml:lang="fr-GB">Juste une clé simple avec un message simple.</cible>
</trans-unit>

Les programmes QT utilisent des fichiers de ressources dont la structure est très proche de ces formats normalisés, mais qui, pour des raisons historiques, ont une mise en page différente.

Listes clés-valeurs simples

Il existe des fichiers de ressources qui ne contiennent que des listings 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 ou plateformes de programmation différents utiliser de tels formats avec des différences Mineure de mise en page.

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 cibles.

Gettext produit des fichiers clé-valeur contenant des informations supplémentaires, comme des commentaires descriptifs ou des variantes plurielles :

# Ceci est la description incroyable pour cette clé !
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Regardez ça ! Cette clé a une description ! (Au moins dans certains formats)"
msgstr[1] "Regardez ça ! 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 du code personnalisé (analyseurs) pour les lire, certains formats sont plus faciles pour les développeurs et les localisateurs. Les formats basés sur les tableaux .JSON (JavaScript) et PHP peuvent être lus et mappés directement dans des structures de code communes (tableaux) 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 désigne les clés comme Identifiantes :

{
    "id": "simple_key",
    "translation": "simple clé, simple message, 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 Mineure mais cruciales, les structures .JSON et PHP Array largement utilisées sont prises en charge.