继续讨论 Fluent相对于通常的gettext的优势，我发表了Fluent 的创作者在翻译中的官方立场 。
Gettext是一个扎根于GNU项目及其关联的体系结构解决方案的本地化系统。
Fluent Project将gettext视为一个完整的，与平台无关的，与平台无关的生态系统的很好的例子，该生态系统用于管理具有可读格式的本地化文件的完整产品发布周期。 同时，Fluent范式将我们带到重要的本地化方面的其他体系结构解决方案，进而导致完全不同的API和生命周期。
换句话说，gettext是一个伟大的项目，但是我们不同意本地化方法。
以下是gettext和Fluent之间的主要区别：
安排
gettext和Fluent之间最重要的区别是消息标识符。 Gettext决定使用源字符串（通常为英文）作为标识符。 这个选择看起来很简单，但是后来施加了许多限制。
首先，使用这种方法，原始行中的任何更改都会使与之关联的所有翻译无效。 这严重增加了开发人员的负担，迫使他们从不更改原始消息，因为这将需要更新所有翻译。
其次，它使源消息中具有相同文本的多个消息的引入变得复杂，必须以不同的方式进行翻译。 例如，由于第一个文本是命令，第二个文本是描述，因此可以用不同的方式来翻译“打开”按钮和“打开”标记的文本。 Gettext具有可选的
msgctxt上下文行，用于区分具有相同源段的行。 这种方法将识别此类情况的责任归于开发人员，这与利益分离原则背道而驰。
正是出于这个原因，Fluent不建议重复使用文本。 将源文本与其他翻译分开对我们输入复合消息（包含一个翻译单元的多行，并附加到一个用户界面小部件）的功能以及基于标识符的消息链接也很重要。
Fluent在开发人员和本地化人员之间建立了“协议”。 开发人员输入一个唯一的标识符和一组变量（未读消息的数量，用户名等），然后本地化程序使用Fluent语法决定如何为该标识符构造消息文本。
开发人员不必担心此类消息翻译的详细实现。 开发人员所需要做的就是获取适合UI中特定位置的一行文本，以通过特定标识符请求字符串。
讯息选项
Gettext支持一小组用于国际化的功能，尤其是复数形式。 但是，除了标准的gettext语法之外，这种复数语法也是一种特殊情况，并且很难扩展到需要可变性的其他情况。
Fluent支持字符串变体的基本概念，可与选择器一起使用。 通常，复数规则将是这样的选择器，但是根据语言的语法特征，可能还有其他选择，例如性别，变形或什至环境-例如一天中的时间或操作系统。 Fluent语法允许定位器考虑所有这些功能，并创建与情况完全匹配的文本。
外部论证
Gettext不支持外部参数。 换句话说，您不能指定参数的格式-数字，日期。 要格式化gettext中的参数，建议返回一个字符串，该字符串将传递给
printf或在结果字符串上运行
String.prototype.replace 。
在Fluent中，对外部参数的支持是语法的核心。 外部参数不仅可以插值，而且还可以用作选择器的参数，也可以传递给内置函数。 这使本地化人员可以针对特定情况创建更准确的文本。 最重要的是，Fluent将
FSI / PDI标记放置在对象周围，以保护双向文本中的方向性隔离，并禁止对叶字符串进行任何操作，从而减轻了开发人员的负担。
责任隔离
另外，gettext处理多个规则的方式要求系统设计人员选择消息是多变量消息还是单行。 从Fluent的角度来看，开发人员不应处理此类问题。 在许多情况下，当一个选项用英语满足要求时，在其他语言中，您需要添加带有复数形式的变体。
Fluent假定开发人员在具有多种语言环境的软件时不应具有类似的语言知识，并且每种语言在本地化期间应具有一定的操作自由度。
结果，Fluent分别存储每个翻译，而不会“泄漏”一种语言的要求给其他人，并且对于不需要担心本地化程序对于给定行可能需要什么功能的开发人员，所有翻译都保持“不透明”。
取消转帐
在开发周期中，在三种情况下，相对于原始版本，翻译被“取消”（变为无效）：
- 小改动：不影响翻译（正确的标点符号，错别字）。
- 中等更改：影响消息的设计，但不会取消关联翻译的正确性（例如， 显示所有书签 -> 显示书签管理器 ）。
- 重大更改：该句子的新含义（ 单击以保存 -> 单击以打开 ）。
出于体系结构原因，gettext将所有三个级别组合为一个称为
Fuzzy的状态。 源代码行的任何更改（至少完整，至少不重要）都会导致翻译被取消。
在Fluent中，使用唯一标识符使您可以将其中两个级别与第三个级别分开：当对行的源文本进行
细微更改时，以及当保存标识符时，翻译将保持有效。 另一方面，如果开发人员更改了标识符，则所有翻译都将被取消并需要更新。
我们相信这样的体系结构解决方案对于大多数发布周期更有利，尽管我们承认对于
中级更改，开发人员将不得不在保存或更改标识符之间进行选择（即在
较小更改与
重大更改之间）。
我们还在考虑消息
版本控制的想法，以便开发人员可以将消息标记为
已更新而不会完全使消息的内容无效。 此状态将使您基于旧版本的翻译仍然比未翻译的字符串更好的观点来使翻译保持有效，并且同时允许工具通知本地化者有关更新翻译的需求。
资料格式
Gettext使用三种文件格式-* .po，* .pot和* .mo。 通过添加诸如提取和编译消息之类的步骤，这会影响生产周期中gettext的实现。
Fluent使用单一* .ftl文件格式，这简化了实现，并且不需要其他步骤即可导致数据差异。
Unicode支持
Gettext可以用UTF-8编码。 通常，这是Unicode支持结束的地方。 它使用自己的复数数据集，不知道如何设置日期和数字的格式，对使用双向文本没有帮助。
Fluent广泛使用标准化库和CLDR，ICU和ECMA402算法，将本地化和国际化巧妙地结合在一起。
结论
我们认为Fluent API和语法比gettext有了显着改进，我们建议您将它们用于国际软件。
更多关于Fluent