- Localisation asymétrique : vise des traductions naturelles en n’utilisant le genre/la casse que lorsque c’est nécessaire. Le pouvoir d’expression n’est pas limité par la grammaire de la langue source
- Amélioration progressive : chaque traduction est gérée indépendamment et n’affecte pas les autres locales. Il est possible d’améliorer les traductions de façon itérative sans impacter les autres langues
- Fonctionnalités variées : formats de date, d’heure et de nombres. Catégories de pluriel. Prise en charge bidirectionnelle. Formats utilisateur. Syntaxe lisible. Traduction et retraduction à l’exécution. Gestion robuste des erreurs
- Open source sous licence Apache. Des implémentations serveur sont proposées en JS, Python et Rust, avec aussi des bindings React
Pourquoi Fluent a été créé
- La localisation logicielle a longtemps été dominée par un paradigme dépassé : la traduction comme correspondance un à un avec une copie en anglais
- La grammaire de la langue source limite le pouvoir d’expression de la traduction
- Fluent a été créé pour changer ce paradigme
- Les traducteurs doivent pouvoir utiliser toute la richesse expressive de leur langue sans demander l’autorisation aux développeurs
- Dans Fluent, les traductions sont asymétriques. Une simple chaîne en anglais peut correspondre à une traduction complexe à variantes multiples dans une autre langue
- Avec Fluent, il est possible de répondre aux exigences grammaticales et stylistiques de différentes langues, indépendamment de la langue source
- Indépendance
- Le fait qu’une langue tire parti d’une logique avancée n’impose pas que d’autres localisations soient nécessaires pour l’appliquer
- Chaque localisation contrôle elle-même le degré de complexité de ses traductions
4 commentaires
Oh, c’est vraiment fascinant de voir qu’on s’éloigne de l’ancien paradigme de correspondance 1:1.
Version dégradée de gettext dédiée à JavaScript.
https://github.com/projectfluent/fluent/wiki/Fluent-vs-gettext
Dit comme ça, on sous-estime beaucoup trop ce projet.
La réponse était tellement peu soignée (?) qu’on peut comprendre que vous l’ayez perçue ainsi. Je vais essayer d’écrire ça de façon un peu plus soignée.
De toute façon, un tableau comparatif est largement déterminé par le point de vue de celui qui compare, donc ça n’a pas une grande signification, mais
si j’ai eu l’impression qu’il s’agissait d’une version au rabais, c’est... parce que j’ai eu le sentiment qu’on ne respectait pas le savoir-faire accumulé dans gettext au fil de longues années par de nombreuses personnes.
Il a été dit que gettext ne fonctionnait qu’avec le langage C, mais parmi les langages majeurs, lequel ne prend pas en charge gettext ?
Vous dites avoir utilisé des paramètres à base de clés pour tenir compte des problèmes d’ordre des mots, mais toutes les langues n’intègrent pas nativement des dictionnaires ; pour ces langages, il faut donc des moyens supplémentaires (par exemple, en Java, quelque chose comme
Map). gettext est basé sur la position, mais la question du changement d’ordre des mots y est bien prise en compte.Je me suis étendu un peu, mais
en réalité... ce qui ne m’avait pas plu dès le début, c’est que ce soit
{$...}au lieu de${...}^^Personnellement, j’aime énormément « réinventer la roue », mais fanfaronner comme si on avait inventé une roue totalement inédite, ça ne me paraît pas très positif.