Poursuivant la discussion sur les avantages de Fluent par rapport au gettext habituel, je publie la position officielle des créateurs de Fluent en traduction.
Gettext est un système de localisation profondément enraciné dans le projet GNU et ses solutions architecturales associées.
Le projet Fluent considère gettext comme un bon exemple d'écosystème complet de bibliothèques et d'outils indépendants de la plate-forme de bas niveau pour gérer le cycle de sortie complet du produit avec des fichiers de localisation dans un format lisible. Dans le même temps, le paradigme Fluent nous amène à d'autres solutions architecturales dans des aspects de localisation importants, qui, à leur tour, conduisent à des API et des cycles de vie complètement différents.
En d'autres termes, gettext est un grand projet, mais nous ne partageons pas son point de vue sur l'approche de la localisation.
Voici les principales différences entre gettext et Fluent:
Arrangement
La différence la plus importante entre gettext et Fluent est l'identifiant du message. Gettext a décidé d'utiliser la chaîne source (généralement en anglais) comme identifiant. Ce choix semble simple, mais impose par la suite de nombreuses restrictions.
Tout d'abord, avec cette approche, tout changement dans la ligne d'origine invalide toutes les traductions qui lui sont associées. Cela augmente considérablement la charge des développeurs, les forçant à ne jamais modifier les messages d'origine, car cela nécessitera la mise à jour de toutes les traductions.
Deuxièmement, cela complique l'introduction de plusieurs messages avec le même texte dans la langue source, qui doivent être traduits de différentes manières. Par exemple, le texte du bouton «Ouvrir» et de la marque «Ouvrir» peut être traduit de différentes manières, car le premier texte est une commande et le second une description. Gettext a une ligne de contexte
msgctxt facultative pour distinguer les lignes avec le même segment source. Cette approche place la responsabilité de la reconnaissance de telles situations sur les développeurs, ce qui contredit le principe de séparation des intérêts.
Fluent ne recommande pas de réutiliser des textes précisément pour cette raison. La séparation du texte source des autres traductions est également importante pour notre capacité à saisir des messages composés (qui contiennent plusieurs lignes pour une unité de traduction, attachées à un widget d'interface utilisateur) et pour les liens basés sur l'identifiant vers les messages.
Fluent établit un «accord» entre les développeurs et les localisateurs. Le développeur saisit un identifiant unique et un ensemble de variables (nombre de messages non lus, nom d'utilisateur, etc.), et le localisateur, à l'aide de la syntaxe Fluent, décide comment construire le texte du message pour cet identifiant.
Le développeur ne doit pas se soucier de la mise en œuvre détaillée des traductions de ces messages. Tout ce dont un développeur a besoin est d'obtenir une seule ligne de texte adaptée à un endroit spécifique de l'interface utilisateur pour demander une chaîne par un identifiant spécifique.
Options de message
Gettext prend en charge un petit ensemble de fonctions pour l'internationalisation, en particulier pour les pluriels. Mais cette syntaxe plurielle est un cas spécial, en plus de la syntaxe gettext standard, et il est difficile de la mettre à l'échelle pour d'autres cas nécessitant une variabilité.
Fluent prend en charge le concept de base de la variation de chaîne, qui peut être utilisé avec des sélecteurs. Habituellement, la règle du pluriel sera un tel sélecteur, mais selon les caractéristiques grammaticales de la langue, il peut y en avoir d'autres, comme le sexe, la déclinaison ou même l'environnement - par exemple, l'heure du jour ou le système d'exploitation. La syntaxe Fluent permet aux localisateurs de prendre en compte toutes ces fonctionnalités et de créer un texte qui correspond exactement à la situation.
Arguments externes
Gettext ne prend pas en charge les arguments externes. En d'autres termes, vous ne pouvez pas spécifier la mise en forme des paramètres - nombres, dates. Pour formater les paramètres dans gettext, il est recommandé de renvoyer une chaîne, qui sera passée à
printf ou exécutera
String.prototype.replace sur la chaîne résultante.
Dans Fluent, la prise en charge des arguments externes est au cœur même de la syntaxe. Les arguments externes sont non seulement interpolés, mais également utilisés comme paramètres pour le sélecteur, et peuvent également être transférés aux fonctions intégrées. Cela permet aux localisateurs de créer des textes beaucoup plus précis pour des cas spécifiques. En plus de cela, Fluent place des marqueurs
FSI / PDI autour des objets pour protéger l'isolement de la directivité dans le texte bidirectionnel et interdit toute manipulation des chaînes de feuilles, réduisant ainsi la charge des développeurs.
Isolement de responsabilité
De plus, la façon dont gettext gère les règles plurielles nécessite que le concepteur du système choisisse si le message sera un message à plusieurs variables ou une seule ligne. Du point de vue de Fluent, le développeur ne devrait pas traiter de tels problèmes. Dans de nombreux cas, lorsqu'une option est suffisante en anglais, dans d'autres langues, vous devez ajouter des variantes avec des pluriels.
Fluent suppose que le développeur ne devrait pas avoir de connaissances linguistiques similaires lors du développement de logiciels avec de nombreux paramètres régionaux et que chaque langue devrait avoir une certaine liberté d'action pendant la localisation.
Par conséquent, Fluent stocke chaque traduction séparément, sans «divulguer» les exigences d'une langue à d'autres, et garde toutes les traductions «opaques» pour un développeur qui n'a pas à se soucier des fonctions dont les localisateurs peuvent avoir besoin pour une ligne donnée.
Annulation d'un transfert
Dans le cycle de développement, il y a trois situations où la traduction est «annulée» (devient invalide) par rapport à l'original:
- Changement mineur: n'affecte pas la traduction (ponctuation correcte, fautes de frappe).
- Changement moyen: affecte la conception du message, mais n'annule pas l'exactitude de la traduction associée (par exemple, Afficher tous les signets -> Afficher le gestionnaire de signets ).
- Changement significatif: le nouveau sens de la phrase ( Cliquez pour enregistrer -> Cliquez pour ouvrir ).
Pour des raisons architecturales, gettext combine les trois niveaux en un seul état appelé
flou . Tout changement dans la ligne source (au moins complet, au moins insignifiant) entraîne l'annulation des traductions.
Dans Fluent, l'utilisation d'identifiants uniques vous permet de garder deux de ces niveaux séparés du troisième: lorsque vous apportez de
petites modifications au texte source d'une ligne et lorsque vous enregistrez l'identifiant, les traductions restent valides. En revanche, si le développeur change l'identifiant, toutes les traductions sont annulées et devront être mises à jour.
Nous pensons qu'une telle solution architecturale est plus avantageuse pour la plupart des cycles de publication, bien que nous reconnaissions que pour les changements de niveau
intermédiaire , le développeur devra choisir entre enregistrer ou modifier l'identifiant (c'est-à-dire entre un changement
mineur et un changement
significatif ).
Nous envisageons également l'idée de la
gestion des versions des messages afin que le développeur puisse marquer le message comme
mis à
jour sans invalider complètement son contenu. Cet état vous permettra de conserver la traduction valide sur la base du fait que l'ancienne version de la traduction est toujours meilleure que la chaîne non traduite, et permettra en même temps aux outils d'informer le localisateur de la nécessité de mettre à jour la traduction.
Format des données
Gettext utilise trois formats de fichiers - * .po, * .pot et * .mo. Cela affecte l'implémentation de gettext dans le cycle de production en ajoutant des étapes telles que l'extraction et la compilation de messages.
Fluent utilise un seul format de fichier * .ftl, ce qui simplifie la mise en œuvre et ne nécessite pas d'étapes supplémentaires pouvant entraîner des écarts de données.
Prise en charge Unicode
Gettext peut être encodé en UTF-8. En général, c'est là que prend fin le support Unicode. Il utilise son propre ensemble de données pour les pluriels, ne sait pas formater les dates et les nombres, n'aide pas à travailler avec des textes bidirectionnels.
Fluent utilise largement les bibliothèques standardisées et les algorithmes CLDR, ICU et ECMA402, combinant parfaitement localisation et internationalisation.
Conclusion
Nous pensons que l'API Fluent et sa syntaxe représentent une amélioration significative par rapport à gettext, et nous vous recommandons de les utiliser pour des logiciels internationaux.
En savoir plus sur Fluent