Fichiers de localisation (Strings)

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 (Strings) 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.) :

Créer de 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éer automatique de fichiers de localisation garantit que les structures de fichiers sont valides.

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 Strings sont ensuite ajoutées au fichier de localisation avec leurs clés.

Utiliser des fichiers de localisation

Au lieu des Strings 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 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 de texte par défaut. Si un utilisateur ne Sélectionner pas de langue, tout le texte sera extrait de ce fichier pour générer tout affichage. Si l'utilisateur Sélectionner 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 Strings

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. Une fois les fichiers téléchargés, les clés et leurs valeurs de chaîne associées sont extraites. Les clés et les Strings 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 Strings sont traduites, les fichiers sont téléchargés. Au cours du processus, les formats de fichier de localisation nécessaires sont créés 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 à quelle fin 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é-valeur 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ères 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 .JSON (JavaScript) et les tableaux .PHP peuvent être lus et mappés directement dans des structures de code courantes (tableaux) qui sont 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.