【专题知识】关于 Attribute Field 和 Text Field
Attribute Field 和 Text Field 是用于标识翻译单元（TU）的自定义信息字段。典型的 TU 包含四个部分，如下图所示：
http://bbs.giltworld.com/UploadFile/2006-11/200611210113711677.jpg【TU 结构示意图】其中的 Client: HP 和 Projcet ID: 001 就是笔者定义的 Attribute Field 和 Text Field。这些字段是项目的信息标识，如果在 Settings －> Project and Filter Settings －> Project Settings 选项卡中设置了 Text/Attribute 字段，在将 TU 提交到 TM 数据库时就会附带上这些字段信息（如上图所示）。
Attribute Field 和 Text Field 的基本区别是，Attribute Field 设定的是可以预见其可能值的信息字段，比如客户名称、产品名称、组件名称、版本号等，使用时在 Project Settings 中选择设置好的字段值；Text Field 定义的是无法预先设定其可能值的标记文本，比如文档的编号，使用时在 Project Settings 中手动输入字段值。
Workbench 默认提供了一个 Attribute Field（名称为 Status，包含 new、approved 和 readonly 三个值）和一个 Text Field（名称为 Text Field）。如果要自定义信息字段，需要以独占方式（exclusive）打开 TM，然后在 Workbench 的 File －> Setup... －> Fields 选项卡中进行定义。定义后，需要在 Project Settings 选项卡中选择 Attribute Field 和/或 Text Field 并指定或输入相应的值。这样，在翻译时，提交到 TM 中的翻译单元就会附加上所选择的信息字段值。
【专题知识】关于 Project Settings 和 Filter Settings
Projcet Settings 用于设置附加到 TU 的信息字段，而 Filter Settings 是利用信息字段从 TM 中筛选翻译单元的一种机制，二者在 Workbench 的 Settings －> Projcet and Filter Settings 对话框中设置。
如果将 TM 看作一个数据库的话，我们对 TM 执行的所有操作都可分为两类：
从 TM 中读取数据 ——
[*]打开翻译单元的过程 － 寻找匹配的 TU 以及将 TM 中匹配的 TU 复制到翻译文档[*]Analyse － 对文档进行分析[*]translate － 对文档进行预翻译向 TM 中写入数据 ——
[*]使用 set 操作，将文档中的翻译单元提交到 TM 中[*]Translate 和 Cleanup 中的 update TM 操作
Project Settings 是针对写入操作的，即每个写入到 TM 的翻译单元（不论是提交翻译单元时写入，还是在 Translate 或 Cleaup 时写入）都会附加 Project Settings 选项卡中设置的字段值；
Filter Settings 是针对读取操作的，即在对 TM 中的翻译单元进行匹配时，如果发现 TM 中的翻译单元的自定义信息字段值（Text Field 和 Attribute Field 值）与 Filter Settings 选项卡中的设置不符（或者不包含选项卡中的设置值），则会按照 Options －> Translation Memory Options －> Penalties 选项卡中 Attribute and Text field differences penalty（默认为 2）所设置的数值对该翻译单元的匹配率进行扣减。
具体来说，如果 TM 中有两个翻译单元 a 和 b，其 TU 的 Source 部分（原文部分）相同，但由于针对的是不同的产品，因此 Target 部分（译文部分）不同，而且附带的字段信息也不同（假设都包含一个 Client 字段，但字段值分别为 IBM 和 HP），如果 Filter Settings 中将 Client 设置为 IBM，当在翻译时遇到这个句子时，a 的匹配率为 100％，而 b 的匹配率则为（100-2）％，因此，Workbench 窗口中会优先显示 a，从而达到了筛选的目的。
【专题知识】关于 Multiple Translation
所谓 Multiple Translation，是指 TM 中同一个 Source Segment（翻译单元 TU 中的原文部分）对应有多个不同的 Target Segment（翻译单元 TU 中的译文部分），即同一 Source Segment 对应有多个 TU。
一般来说，如果出现了 Multiple Translation，在原则上即违反了一致性（Consistency），但有的时候某一句原文确实可能有多个翻译，比如 password 一词，在 Windows 系统和 Unix 系统就有不同的说法，分别为“密码”和“口令”，如果 TM 中有必要包括这两种翻译，则存在 Multiple Translation 就有其合理性。另一方面，存在 Multiple Translation 会降低 TU 的匹配率（会按 Options －> Translation Memory Options －> Penalties 选项卡中 Attribute and Text field differences penalty 所设置的数值对存在 Multiple Translation 的翻译单元的匹配率进行扣减），会给客户造成一定的成本损失，同时也会给后续的翻译工作带来麻烦，因此，大多数情况下，我们需要避免不必要的 Multiple Translation。
TM 中出现 Multiple Translation 主要有三种可能途径：
a、创建 TM 数据库时选中了 Allow multiple translation for identical source segments（注1）选项，翻译文档时，如果某句原文在 TM 中存在完全匹配的 TU，但你在文档中对其译文部分进行了修改，并且使用 Workbench 菜单中的 Add as new translation 菜单项提交（如果是在 Tageditor 中），或者使用 Trados 菜单中的“添加新译文”菜单项提交（如果是在 Word 中），则这种情况下会添加一个新的翻译单元。如果以正常方式提交，则会覆盖原来的翻译单元。
b、创建 TM 数据库时选中了 Allow multiple translation for identical source segments 选项，这种情况下，Options －> Tranlsation Memory Options －> Tools 选项卡下的 Always add new translation unit when target segments differ 选项将处于可选用状态。如果选中了这个选项（注意：Tools 选项卡中的设置都是用于批处理 Analyse、Translate 和 Cleanup 的），在 Translate 和 Cleanup 等批处理过程中更新 TM 时，对于同一原英文，只要译文不同，就会添加一个新的翻译单元，而不是覆盖原有的内容，这样，如果文档中存在 Multiple Translation 的情况，都会体现在 TM 中。很多客户使用这个选项来检查所提交的文档中是否存在 Multiple Translation。
c、在创建 TM 数据库时无论是否选中了 Allow multiple translation for identical source segments 选项，对于某个已在 TM 中存在的翻译单元，如果在翻译文档时修改了该翻译单元的翻译内容，并且当前 Project Settings 中设置的信息字段值与 TM 中该翻译单元的信息字段值不同且前者不是后者的一个子集（注2）（比如 TM 中该翻译单元的标记为 client=IBM，而当前的 Project Settings 中的设置为 client=HP），则提交后会生成一个新的翻译单元，并附带 Project Settings 中设置的信息字段值。
注1：如果在创建 TM 数据库时选中了 Allow multiple translation for identical source segments 选项，则会产生 3 个变化： ① 如果文档中的某句原文在 TM 中有完全匹配的 TU，则在文档中打开该翻译单元时，Workbench 菜单中的 Add as new translation 菜单项将处于可用状态（如果使用的是 Tageditor，但 Word 的 Trados 菜单中的“添加新译文”菜单项始终会处于可用状态）；
② Workbench 的 Options －> Translation Memory Options －> Penalties 选项卡中的 Attribute and Text field differences penalty 选项处于可选用状态；
③ Workbench 的 Options －> Tranlsation Memory Options －> Tools 选项卡下的 Always add new translation unit when target segments differ 选项将处于可选用状态
否则，如果在创建 TM 数据库时没有选中 Allow multiple translation for identical source segments 选项，上述三个选项都将处于不可用的灰显状态。
注2：这里子集的意思是，从数学集合的角度来看，TM 中该 TU 的信息字段的内容包含 Project Settings 中的信息字段设置。比如，在 Project Settings 中设置了一个 Client 字段，并指定 HP 作为其字段值，则 Project Settings 的设置结果是“Client = HP”，如果当前 TU 的信息字段值为“Client = HP,IBM”，则后者包括前者，前者即为后者的一个子集。
【专题讨论】字数分析（Analyse）的影响因素
Analyse 的作用就是确认文档中可翻译的内容，然后以翻译单元（TU）的形式在 TM 中进行匹配，最后统计匹配结果。实际上，前面这句话就已经概括了 Analyse 的四个过程：
一、确定可翻译的内容 二、对可翻译内容划分翻译单元（TU）
三、与 TM 中的 TU 进行匹配
四、统计匹配结果
下面具体分析有哪些因素会影响上述过程并最终影响字数分析结果。
一、确定可翻译的内容
1、标记语言文件
HTML 或 XML 这类标记语言文件主要包括两部分内容：“用于设置文本显示格式或处理方式的标记符号”、“实际显示的文本内容”，前者我们称其为 Tag。在对这类文档进行分析时，需要使用到 DTD Setting 文件（ini 文件）。每种标记语言文档都有对应的 DTD Setting 文件，该文件记录了特定类型标记语言文件的文件结构、所包含的元素以及一些文档约定。
Workbench 在进行 Analyse 时需要使用对应的 DTD Setting 文件来区分文档中的 Tag 和可翻译的内容；在将 HTML 或 XML 文件转换为 Tageditor 可处理的 TTX 文件中，也需要使用 DTD Setting 文件来区分 Tag 和可翻译内容。Tag 可分为内部 Tag 和外部 Tag，使用 Tageditor 打开 HTML 文件后，可以看到使用 DTD Setting 文件处理后的结果，其中灰色的 Tag 为外部 Tag，不进入翻译单元，红色的 Tag 为内部 Tage，可以进入翻译单元，而其他的可翻译内容则是构成翻译单元的主体。
由于同一种类型的标记语言文件会对应有多个适用的 DTD Setting 文件，而这些 DTD Setting 文件在处理具体的 Tag 时会有所差别，比如对于某个 Tag，不同的 DTD Setting 文件可能会将其处理为内部 Tag、外部 Tag，甚至可能处理为可翻译内容。
因此来说，DTD Setting 文件至少会在两个方面影响分析结果：
a、对于特定 Tag，将其仍处理为 Tag 还是处理为可翻译的内容会影响到可翻译内容的字数统计。在具体统计翻译内容时，外部 Tag 不进入统计，内部 Tag 会统计为 Placeable 而非字数。由于文档中 Tag 内容数量有限，处理为 Tag 还是可翻译内容对于整个统计字数影响不大，但总会有一些影响；
b、对于特定 Tag，处理为内部 Tag 还是外部 Tag 会影响到翻译单元的划分。我们知道，外部 Tag 是不进入翻译单元的，也就是说，不论 Segmentation rule 如何设置，遇到外部 Tag，翻译单元都会结束，相反，内部 Tag 是可以进入翻译单元的，因此来说，处理为内部 Tag 还是外部 Tag 会影响翻译单元的划分，而同一文档按不同的方式划分翻译单元，匹配结果肯定会有差别。在这一方面，DTD Setting 文件的选用对于字数分析可能会有很大的影响。
有关 DTD Setting 文件的注意事项，请参阅本贴“Tools 选项卡”说明。
2、RTF 文件
一般来说，本地化过程要翻译的 rtf 文档都是处理过的，某些文档会处理为三个部分：灰色部分、黑色部分和红色部分，其中灰色部分可看作外部 Tag，不进入翻译单元，红色的部分可看作内部 Tag，可进入翻译单元，黑色部分是要翻译的内容，进入翻译单元。还有一些文档不包含这些灰色和红色内容。
但不管怎样，在 Workbench 中，还有一类设置会影响到实际可翻译的内容，那就是 Non-translatable 设置。这里所谓的 Non-translatable 是针对使用 Word 编辑的文档而言的，具体来说，Non-translatable 设置用来确定哪些样式的文本内容无需翻译。在 Workbench 中有两处设置 Non-translatable 的位置：
a、File －> Setup... －> Non-translatable Text 选项卡
该选项卡用于指定将哪些样式的文本字符作为无需翻译的内容来对待。在具体指定时可以选择将特定样式的文本字符处理为内部 Tag 或外部 Tag。其对于字数分析的影响和 DTD Setting 文件的情况类似。
b、Settings －> Non-translatable Paragraphs 对话框
该对话框与 Non-translatable Text 选项卡的区别是，前者处理的是段落或句子样式，而后者处理的是字符（这里是词的意思，即英文的 word）样式。如果指定某种样式为 Non-translatable Paragraph 内容，则使用该样式的文本不记入可翻译字数，也不记入 Placeable。有关该对话框的设置，请参阅本贴“Non-translatable Paragraphs 对话框”的说明。
二、对可翻译内容划分翻译单元（TU）
在分析文档时，Workbench 使用所谓的“UI 划分规则”（Segmentation Rule，在 File －> Setup... －> Segmentation Rule 选项卡中设置）来确定翻译单元的结束位置，以此来划分翻译单元，该规则的设置保存在 TM 数据库中。比如，默认的 Segmentation Rule 将“句号”、“冒号”、“问号”、“叹号”、“Tab 符号”以及“段落结束”均视为翻译单元的结束标记。
如果 TM 库中保存的翻译单元的划分规则与当前在上述 Segmentation Rule 选项卡中设置的划分规则不一致，则会影响到分析结果。这里做一个极端的测试。首先在 Segmentation Rule 选项卡中将“划分规则”指定为默认规则，然后翻译某个文档，翻译完成后，修改 Segmentation Rule 选项卡中的设置，只保留 End of Paragraph 规则而将其他规则删除，然后使用 TM 分析已翻译过的原文档，你可能已经猜到了结果。统计结果表明，本来应该完全匹配的文档由于修改了 Segmentation Rule 而几乎完全变成了 No match 的情况（有关示例，请参见本贴“新手入门 3”部分的相关说明）。
因此，不同的 Segmentation Rule 对于分析结果可能会产生重大的影响。
Segmentation Rule 设置保存在 TM 库中，所以，只要没有用错 TM，就不会出现这种情况，但也不能掉以轻心。比如某些文档过于久远而忽略了当初使用的 Segmentation Rule，当 Cleaup 到新的使用不同 Segmentation Rule 的 TM 时，在进行翻译和字数分析时就会出现这类问题。当然翻译人员可以使用 Expand Segment 和 Shrink Segment 来扩展或缩小文档中的翻译单元，使之在形式上与 TM 中翻译单元的 Segmentation Rule 一致，但对于字数分析的影响却不易觉察到，这可能会造成很大的成本损失。
三、与 TM 中的 TU 进行匹配
这里需要指明一点，在获得 TU 的匹配率时，除了计算文本匹配率，Workbench 还会考虑 TU 的 Source 部分的格式差异、是否包含要保留为英文的 Placeable 内容、该 TU 是否由 WinAlign 生成、TU 的自定义信息字段是否与 Filter Settings 的设置匹配、是否存在 Multiple Translation 等因素，Worbkbench 会根据上述情况在翻译单元文本匹配率的基础上扣减匹配值来获得最终的匹配结果，这就是所谓的 Penalty 设置，有关该设置的具体说明，请参阅本贴的“Penalties 选项卡”说明。另外需要指明，Filter Settings 选项卡中的设置与 Penalties 选项卡中的 Attribute and text field differences penalty % 设置密切相关，二者共同影响匹配结果，具体情况，也请参阅本贴的“Penalties 选项卡”有关 Attribute and text field differences penalty % 部分的说明。
实际上，在统计结果的 95％－99％ 统计项中，很多统计的都是属于文本完全匹配但应用了 Penalties 设置的文本内容，特别是匹配率为 98％ 和 99％ 的翻译单元。
四、统计匹配结果
Analyse 的最后一步是将匹配结果进行分类统计。上文提到，Analyse 会将统计的文本内容分为 Xtranslated、Repetitions、100% match、Fuzzy match 和 No match 五类。而 Fuzzy match 部分又细分为 95%－99%、85%－94%、75%－84%、50%－74% 四类。我们知道，在 Workbench 中使用 Minimum match value %（在 Options －> Translation Memory Options －> General 选项卡设置）值来区分 No match 与 Fuzzy match，因此，该值的设置会影响到翻译单元的统计归属。
举个例子，某个翻译单元的匹配率为 80％，如果将 Minimum match value % 设置为小于或等于 80％，则该翻译单元会统计到 75%－84% 这一列；但如果将 Minimum match value % 设置为超过 80％，则该翻译单元就会统计为 No match。
因此，不同的 Minimum match value % 设置会影响非 100％ 匹配的翻译单元的统计归属，进而会影响到最终的统计结果。
下面对以上内容做一个小节：
一、确定可翻译的内容
a、DTD Setting 文件。该设置保存在装有 Workbench 的本地机器中。
b、Non-translatable 设置。该设置保存在 TM 中。
二、对可翻译内容划分翻译单元（TU）
Segmentation rule 选项卡设置。该设置保存在 TM 中。
三、与 TM 中的 TU 进行匹配
Penalties 选项卡与 Filter Settings 选项卡设置。前者保存在装有 Workbench 的本地机器中，后者与 TM 有关。
四、统计匹配结果
Minimum match value % 设置。该设置保存在装有 Workbench 的本地机器中。
最后需要说明：
a、这里之所以强调设置是保存在 TM 中还是保存在装有 Workbench 的本地机器中，其目的在于说明，如果设置保存在 TM 中，则使用任何计算机上的 Workbench 打开 TM，这个设置都不变；而如果是保存在装有 Workbench 的本地机器中，则使用某个计算机上安装的 Workbench 打开任何 TM 时该设置都不变。明确了这一点，在进行 Analyse 时就可以有针对性地检查和调整相应设置。
b、字数分析结果关乎成本收益，在确认这些设置时，首先应与客户的设置保持一致，如果客户未指定设置，则最好使用默认的设置，并同客户确认，以免造成不必要的误差和成本损失。
以上内容如有错误，请网友及时帮助指出，以免以讹传讹，贻误他人。
【专题讨论】关于 Use TM from previous analysis 选项的应用
上文说道，Workbench 在执行 Analyse 时会生成一个临时的 TM 库，并在分析过程中将文档中的所有翻译单元逐个保存在这个临时 TM 中，分析结束后，在不关闭 Analyse 对话框的情况下，可以选中 Use TM from previous analysis 选项，使用这个临时 TM 来继续分析。那么使用临时 TM 库的分析过程与使用正式的 TM 库有什么区别吗？这个选项的作用何在呢？本文对此进行一些尝试性的探讨。
一、使用临时 TM 与正式 TM 在执行 Analyse 时的区别
在上文有关 Analyse 对话框的说明中，给出了使用正式 TM 库执行 Analyse 的逻辑过程和相应图示。通过测试发现，使用临时 TM 库执行 Analyse 与使用正式 TM 库有一些不同。导致这一差别的主要在因素在于，在分析过程中，正式的 TM 库是不变的，而临时的 TM 库却是在不断的加入分析过的翻译单元，而这些新加入的翻译单元又会同后续要分析的翻译单元存在 Fuzzy match 的情况。换句话说，使用临时 TM 库分析某个文档时，与我们翻译这个文档的过程是类似的。在翻译文档的过程中，我们会不断的将翻译单元提交到 TM 中，而这些提交后的翻译单元又可能与我们后续的翻译内容存在一定的匹配，使用临时 TM 库的过程也大致如此。
具体来说，无论是使用正式 TM 库还是临时 TM 库进行分析，如果文档中有两句原文完全相同，并且第一句的分析结果为 Fuzzy match 或 No match，那么分析第二句时，会将其记为 Repetition，这类情况下，两种方法的分析结果是一致的；如果文档中有两句原文类似但不完全相同，并且它们在 TM 中的匹配都为 No match，那么使用正式 TM 分析时，这两句原文会全部记为 No match，但使用临时 TM 进行分析时，第一句原文会记为 No match，但由于分析之后这句原文所对应的翻译单元就加入到临时 TM 库中，因此在分析第二句原文时，结果就可能是 Fuzzy match。
请看下面的示例：
现在要使用一个空的 TM 库对以下文档进行分析，该文档包含三句话，它们之间类似但并不完全相同：
http://bbs.giltworld.com/UploadFile/2006-12/2006122414505211631.jpg（UTF-1）
首先使用空的 TM 库直接对该文档进行分析，结果如下： http://bbs.giltworld.com/UploadFile/2006-12/2006122414511631450.jpg（UTF-2）
然后将 Analyse 对话框关闭并重新打开（因为此时临时 TM 库已包含了这三个翻译单元），先分析一个不包含任何内容的空 RTF 文档，该文档与分析结果没有任何关系，但通过分析这个空文档就可以启用 Use TM from previous analysis 选项。分析完空文档之后（此时，临时 TM 中没有任何翻译单元），选中该选项，使用临时 TM 库分析以上文档，其结果如下： http://bbs.giltworld.com/UploadFile/2006-12/200612241451598153.jpg（UTF-3）
可以看到，在第一个 log 中，三个句子全部分析为 No match，而在第二个 log 中，只有一个句子结果为 No match，其他两个句子的匹配结果是 Fuzzy match，造成这种差异的原因就是临时 TM 库在分析时会不断加入分析过的翻译单元。
二、Use TM from previous analysis 选项的应用
从上面的叙述中你可能已经意识到，这个采用临时 TM 库的方式似乎能够省钱，某种情况下，确实如此，请看以下案例：
1、某本地化部门承接了一个软件本地化项目，软件部分和联机帮助部分已经翻译完毕，马上需要翻译两个 PDF 帮助文档，暂称为“文档 1”和“文档 2”，这两个文档与前面完成的翻译内容关系不大，当两个文档之间有很多相同或类似的内容。该部门的 PM 现在需要向客户确认这两个文档的统计字数（工作量），但客户要求采用一种特殊的字数分析方案，该方案的过程是：首先打开 Analyse 对话框，使用当前已有的 TM 分析第一个文档，不关闭对话框，选中 Use TM from previous analysis 选项，然后分析第二个文档。
PM 将使用常规方式的分析结果（暂称为 log1）与采用客户方案的分析结果（暂称为 log2）进行了比较，发现 log1 和 log2 的 100％ 和 Repetition 部分基本没有什么差异，但 Fuzzy match 和 No match 部分差异比较大，具体表现是，log1 的 No match 部分比 log2 多，而 Fuzzy match 部分比 log2 少，两个 log 统计下来，log2 计算出的成本要比 log1 少许多，我们从第一部分的叙述中不难判断导致这种情况的原因。
那么是否这种方案就一定优于常规方案或者说比常规方案节省成本呢？这要视具体情况而定。本文中的这个案例的前提是：文档与 TM 的关系不大，但文档内部或文档之间有很多相同或类似的内容。实际上，使用临时 TM 库的优势在于利用文档内部翻译单元的相关性来降低成本，其缺点是无法充分利用正式 TM 库的资源。因此在判断是否采用这种方案时，需要权衡这两个因素。
不过，需要说明的是，这种非常规的方式实际上很少采用，如果使用的话，应该在本地化部门、客户和兼职翻译之间确认并达成一致，否则三方的分析结果就会存在差异。另外，当处理多个文档并且分配给多个兼职人员来做时，如果这些兼职人员无法实现共享 TM 库，则兼职人员实际处理的字数可能要多于此种情况下 log 的分析结果，因为每个翻译人员都无法使用别人的翻译结果，而此种分析方式的一个暗含假定就是翻译过程中始终使用同一个 TM。注1。
2、Use TM from previous analysis 选项的另一个应用就是比较文件。如果希望确定两个文件或两批文件的雷同性，可以先使用 TM 分析第一个文件或第一批文件，然后选中 Use TM from previous analysis 选项使用临时 TM 库分析第二个或第二批文件，由第二次分析结果中 Fuzzy match 和 No match 的多少来确定它们的差异程度。使用这种方法可以确定不同版本的同一类文档的差异性；在考虑对文档进行 Xtranlslate 处理时，也可以通过这种方式确定文档之间的相似程度，以判断是否适合使用 Xtranslate 来处理。
注1：实际上，即使使用常规方式来分析多个文件，在将这些文件分配给多个无法共享 TM 的兼职人员来做时，也会遇到类似情况。问题的焦点在于 Repetition 部分。我们知道 Repetition 部分是重复出现的匹配率为 No match 或 Fuzzy match 的翻译单元，这类翻译单元在第一次出现时记为 No match 或 Fuzzy match，后续再出现同样的内容就会处理为 Repetition。但在为多个译员分配文件时，并不能够保证第一个翻译单元与相应的 Repetition 部分分配给同一个译员。 综合看来，在使用常规方式进行分析时，与使用临时 TM 库相比较，分析出来的字数可能会比译员的实际工作量要多，但在将文件分配给多个译员时，又可能会出现以上所述的增加译员实际工作量的情况。二者似乎可以扯平。
以上内容只是客观的进行分析，并不体现本文作者的任何观点倾向，如有不当，恳请网友及时指正。
关于 Project and Filter Settings 选项卡以及 Attribute 和 Text 字段的应用
在阅读本贴前，如有必要，请参阅以下链接：
[*]关于 Attribute Field 和 Text Field[*]关于 Project Settings 和 Filter Settings[*]关于 Multiple Translation（Project Settings 导致 Multipel Translation 的说明）[*]Project and Filter Settings 对话框[*]General 选项卡（续）（有关 Textv/Attribute 的说明）[*]Penalties 选项卡（有关 Attribute and text field differences penalty ％ 的说明）
大体来讲，Project Settins 选项卡的作用就是为提交到 TM 中的 TU 附加信息标记（这里称为自定义字段值），Filter Settings 选项卡的作用就是通过 TM 中的 TU 所附带的这些信息标记来筛选 TU，其筛选机制就是，如果 TM 中的某个 TU 所附带的信息字段值与当前 Projcet Settings 中的设置不符，在确定该 TU 的匹配率时，就按 Attribute and Text field differences penalty 值（Options －> Translation Memory Options －> Penalties 选项卡）扣减匹配率；而对于信息字段值与 Project Settings 完全相符的 TU 则不会进行扣减，因此，在设置 Filter Settings 的情况下，如果有多个文本匹配率相同的 TU，则会对与 Filter Settings 设置不符的 TU 的匹配率进行扣减，在 Workbench 窗口优先显示与 Project Settings 设置相同的 TU，从而达到筛选的目的。（相关内容，请参阅上述文档）。
因此来说，如果希望提交到 TM 中的 TU 附带相应的信息标记以便于区分，就可以使用 Project Settings 来达到目的。比如，你要使用一个 TM 库来保存多个项目的翻译单元内容，使用同一个 TM 保存来自多个客户的项目，或者使用一个 TM 来保存来自同一项目的多个不同组件、版本、文档的翻译单元，在翻译这些内容时，就可以设置相应的 Projcet Settings，使得提交到 TM 的 TU 附带相应的标记。
为翻译单元附加信息标记的初衷就是标识或区分不同来源的翻译单元。翻译单元附加了信息标记后，会带来很多便利：
[*]首先，翻译人员在重用 TM 中的 TU 时，可以根据信息标记来判断 TU 的来源（不同客户、产品、组件、版本、文档），以确定是否采用；[*]其次，可以使用 Filter Settings 在“翻译文档”、进行“预翻译”和“字数分析”时，优先使用符合筛选条件的翻译单元；[*]在使用 Export 对话框（File －> Export）从 TM 中导出翻译单元时，以及使用 Maintenance 对话框（File －> Maintenance）维护 TM 时，可以按 Attribute 和 Text 字段值设置筛选条件，只导出符合条件的 TU，或者只对符合条件的 TU 进行维护；[*]......当然，在设置 Project Setttings 前，应该清楚它所带来的影响，如果设置了 Projcet Settings，无论你是在翻译过程中提交翻译单元，还是执行 Translate（预翻译）、Cleanup（清除原文及更新 TM），总之，只要是向 TM 中写入（或修改）TU 数据，就会在 TU 上附加 Projcet Settings 中的设置。
另一方面，对于 Filter Settings，无论你是打开翻译单元进行匹配，还是执行 Analyse（字数分析）和 Translate（预翻译），总之，只要是从 TM 中读取 TU 数据进行匹配，就会应用筛选条件。特别是，在进行“预翻译”和“字数分析”时，切记要检查并确认是否需要设置 Filter Settings，因为这个设置会影响到匹配率，将本来应该 100％ 匹配但不符合筛选条件的 TU 处理为 fuzzy match，如果这不是你所期望的结果，那么就不要设置 Filter Settings。
简而言之，如果使用 Project Settings 和 Filter Settings，就要充分了解它们所带来的影响，否则，最好不要使用。
以下设计一个案例，具体说明 Projcet Settings 和 Filter Settings 的应用：
某本地化部门翻译了一批来自 IBM 的文档，完成翻译任务后，需要对这批文档进行 Cleanup，以清除文档中的原文并生成完整的 TM。为了使在 Cleanup 过程中提交到 TM 的 TU 附带上相应的项目标记，在执行 Cleanup 前，首先在 File －> Setup －> Fields 选项卡定义了一个 Attribute 字段，字段名为 Client，并为其定义了一个字段值“IBM”，然后，在 Projcet Settings 选项卡中通过选择将 Project Settings 设置为 Client=IBM，最后执行 Cleanup。在 Cleanup 过程中，提交到 TM 的翻译单元就会附带 Client=IBM 标记。
而后，该部门又承接了一个来自 HP 的项目，巧的是，这个项目中好多文档的内容与先前 IBM 的那批文档相同或类似，因此，项目经理决定在翻译过程中使用 IBM 那个项目的 TM 库。项目经理对于 TM 库的使用进行了如下设想：
[*]在翻译 HP 的项目时，提交到 TM 中的 TU 需要附带 Client=HP 标记；[*]如果在翻译过程中遇到了 100％ 匹配的 TU，并且该 TU 是上一个 IBM 项目的 TU， 若是重用该 TU 的翻译内容而不做修改，则提交时希望保留该 TU 原来的 Client=IBM 标记，但也要在其中加入 HP 标记；[*]如果在翻译过程中遇到了 100％ 匹配的 TU，并且该 TU 是上一个 IBM 项目的 TU， 但在翻译当前文档时修改了对应的翻译部分，则希望在提交时保留原有的 TU，并增加一个新的包含修改后内容的 TU，同时在新增的 TU 中附带 Client=HP 标记；[*]上面的这个情况会导致 TM 中对于同一原文存在两个对应的 TU，因此如果在翻译中再次遇到同一翻译内容，希望在 Workbench 窗口中优先显示带有 Client=HP 标记的 TU；[*]当某个 TM 中的 TU 的文本匹配率为 100％ 时，如果它没有附带 Client=HP 标记，希望扣减其匹配率以提醒翻译人员注意。上文说道，那个 IBM 的 TM 中已定义了一个 Client 字段，并且为其定义了一个值 IBM。在实施以上设想时，项目经理在这个 TM 库中又定义了一个 Client 值“HP”，然后进行以下设置：
[*]规定翻译人员在使用 TM 前在 Project Settings 选项卡中设置 Client=HP，这样翻译过程中提交到 TM 的翻译单元就会附带 Client=HP 标记。[*]通过在 General 选项卡（Options －> Tranlsation Memory Options 对话框）中的 Updating attribute and text field 区域左侧设置 merge 选项，使得那些在 IBM 和 HP 的文档里翻译完全一致的翻译单元只保留一个，并且其 field 标记合并在一起：Client= IBM, HP。（请参阅 General 选项卡（续））[*]在 Project Settings 中将 Client 设置为 HP，当在 HP 的文档中修改了 TM 中已存在的且标记为 Client=IBM 的 TU，提交后，由于译文部分不同，并且原有的 TU 标记（Client=IBM）与当前 Projcet Settings 中的设置（Client=HP）不一致，则会提交一个新的翻译单元，并附带 Client=HP 标记。（请参阅 General 选项卡（续））[*]在 Filter Settings 中选择设置 Client=HP，这样，使得在 TM 中只有带有 Client = HP 标记的翻译单元才可能具有 100％ 的匹配率，而对于那些标记为 Client= IBM 的翻译单元，则会扣减其匹配率（请参阅“Penalties 选项卡”有关 Attribute and text field differences penalty ％ 的说明）。因此，对于文本 100％ 匹配的翻译单元，如果其标记为“Client =HP”或“Client=IBM, HP”，则不会扣减其匹配率，但如果其标记为 Client=IBM，则会进行扣减，从而起到在 Workbench 窗口优先显示带有 Client=HP 标记的 TU 的目的。
关于 Project and Filter Settings 选项卡以及 Attribute 和 Text 字段的应用(教程内容)
Text Field 和 Attribute Field 是用于设置翻译单元（TU） 的标识标记的，具体来说，如果在 Project Settings 面板中选择了 Text Field 或 Attribute Field 值，则在翻译时，提交到 TM 中的翻译单元都会附加上所选择的 Field 标记。而 Filter Settings 是利用 Field 标记从 TM 中筛选翻译单元的一种机制。
如果将 TM 看作一个数据库的话，我们对 TM 执行的所有操作都可分为两类：从 TM 中读取数据（包括 get 操作 － 将 TM 中匹配的翻译单元复制到翻译文档、Analyse － 对文档进行分析、translated － 对文档进行预翻译）；向 TM 写入数据（使用 set 操作 － 将文档中的翻译单元提交到 TM 中、Translated 和 Cleanup 中的 update TM）。
Project Settings 是针对写入操作的，即每个写入到 TM 的翻译单元（不论是提交翻译单元时写入，还是在 Translate 或 Cleaup 时写入）都会附加该面板中的设置值；
Filter Settings 操作是针对读取操作的，即在对 TM 中的翻译单元进行匹配时，如果发现 TM 中的翻译单元的标记值（Text Field 和 Attribute Field 值）与其面板中的设置不符（或者不包含面板中的设置值），则会按照 Options －> Translation Memory Options －> Penalties 选项卡中 Attribute and Text field differences penalty（假设为 2）所设置的数值对该翻译单元的匹配率进行扣减。
具体来说，如果 TM 中有两个翻译单元 a 和 b，其 TU 的 source 部分相同，但由于针对的是不同的产品，Target 部分不同，而且 Field 标记也不同（假设都包含一个 client 字段，但具体的 field 值分别为 IBM 和 HP，具体如何定义/设置 Field 和相应的值，请参见楼主提供的教程），如果 Filter Settings 中 client 设置为 IBM，当在翻译时遇到这个句子时，a 的匹配率为 100％，而 b 的匹配率为（100-2）％，因此，Workbench 窗口中会优先显示 a（可以通过 Workbench 窗口左下角的 < 和 > 来显示 b），从而达到了筛选的目的。
你还希望这些字段被合并入所用到的翻译单元中，又不改变原有翻译单元。
对于这句话解释如下：
假设楼主所提供的 pdf 教程中所谈到的两个客户分别为 IBM 和 HP。已经为客户 IBM 翻译了一个文档，并且在翻译时使得每个翻译单元都附带了 client=IBM 标记，这次要为HP 翻译文档，而这个文档几乎与 IBM 的那个文档完全相同，但其中的某些句子要采用不同的翻译（比如 password 可能要翻译为“口令”而不是 IBM 文档中的“密码”）。
翻译 HP 这个文档时，在 Project Settings 中将 client 设置为 HP（使得提交的每个翻译单元都附加 client=HP 标记），在 Filter Settings 中也将 client 设置为 HP（使得只有在遇到标记有 client＝HP 的完全匹配的翻译单元时，才显示为完全匹配）。
在具体翻译 HP 的文档时，会遇到两种情况：
1、在翻译 HP 的文档的过程中，某些句子使用 TM 中已保存的 IBM 文档的翻译单元内容而不做修改，这些翻译单元在 TM 中带有 client= IBM 标记。在提交这类翻译单元时，由于要附加上 Project Settings 中设置的 client=HP，那么如何处理原来翻译单元的标记 client= IBM？一般来说有三种处理方式：保留原来标记、合并、覆盖原来的标记，这可以在 Options －> Tranlsation Memory Options 中 General 选项卡下 Updating attribute and text field 区域左侧进行设置，如果设置为 merge，则提交后，该翻译单元的标记由原来的“client= IBM”变为“client=IBM, HP”，即标记值合并在一起。
2、还有一种情况就是修改了 TM 中原有的翻译单元的翻译内容并提交。
这里需要交代一下，为了保持一致性，Workbench 设计了避免 TM 中存在 Multiple Translation 的机制，而所谓的 Multiple Translaion 就是 TM 中同一个 source（比如同一句原英文）出现多个翻译的情况。但在某些情况下是允许 TM 中出现 Multiple Translation：
a、在创建 TM 数据库时选择了 Allow multiple translation for identical source segments 选项，在提交 TM 中已存在的某个翻译单元前在翻译文档中修改了相应的翻译内容，并且使用Tageditor 的 Workbench 菜单中的 Add as new translation 菜单项提交，或者在 Word 中使用 Trados 菜单中的“添加新译文”菜单项提交，则会添加一个新的翻译单元。如果正常提交，则会覆盖原来的翻译单元。
b、在创建 TM 数据库时选择了 Allow multiple translation for identical source segments 选项，这时，Options －> Tranlsation Memory Options 中 Tools 菜单下的 Always add new translation unit when target segments differ 选项将处于可选中状态，Tools 选项卡中的设置都是用于批处理（Analyse、Translate 和 Cleanup ）的，选中了这个选项后，在 Translate 和 Cleanup 等批处理过程中更新 TM 时，对于同一原英文，只要翻译不同，就会添加一个新的翻译单元，而不是覆盖原有的内容，很多客户使用这个选项来检查所提交的文档中是否存在 Multiple Translation 的情况。
c、无论是否在创建 TM 数据库时选择了 Allow multiple translation for identical source segments 选项，对于某个已在 TM 中存在的翻译单元，如果在翻译文档时修改了该翻译单元的翻译内容，并且当前 Project Settings 中的设置与 TM 中该翻译单元的标记不同（比如 TM 中该翻译单元的标记为 client=IBM，而当前的 Project Settings 中的设置为 client=HP），则提交后会生成一个新的翻译单元。
上述的第三种情况就是文档中客户所期望的结果，即对于同一句话，如果 IBM 的文档和 HP 的文档需要使用不同的翻译，则在翻译 HP 的文档时，会创建新的附带 client= HP 标记的翻译单元，并保留原来标记为 client=IBM 的那个翻译单元。这时，对于同一句 source，会对应有两个翻译单元，分别附带 client= HP 和 client= IBM 标记，且翻译内容不同。
综上所述，通过一些设置，达到了以下目的：
1、为了能够区分哪些翻译单元是针对 IBM 的，而哪些翻译单元是针对 HP 的，在 Workbench 的 File －> Setup －> Fields 选项卡中定义一个 attribute 字段 client，并为其定义两个值 HP 和 IBM。在翻译 HP 和 IBM 的文档时，可分别在 Project Settings 中设置相应的值，使得翻译过程中提交到 TM 的翻译单元附带相应的标记。
2、通过在 Project Settings 中将 client 设置为 HP，使得当在 HP 的文档中修改了同样出现在 IBM 文档并已提交到 TM 的翻译单元时，提交后会生成新的翻译单元。这时，对于某一句在 IBM 和 HP 的文档中有不同翻译的英文，在 TM 中会有两个翻译单元，分别附加不同的标记：client=IBM 和 client=HP。
3、通过在 Options －> Tranlsation Memory Options 中 General 选项卡下 Updating attribute and text field 区域左侧设置 merge 选项，使得那些在 IBM 和 HP 的文档里翻译完全一致的翻译单元只保留一个，并且其 field 标记合并在一起：client= IBM, HP。
4、通过在 Filter Settings 中将 client 设置为 HP，使得在 TM 中只有带有 client = HP 标记的翻译单元才可能具有 100％ 的匹配率，如果本来文本完全匹配的翻译单元的标记为 client= IBM，则该翻译单元的匹配率也只有 98％。即只有标记为“client =HP”或“client=IBM, HP”的翻译单元才可能完全匹配。从而起到了筛选的作用。
翻译过程中使用 TM 库的一个方案设想 ——
有关 Do not create new translation units if only text fields differ 的一个应用 在阅读本贴前，如有必要，请参阅以下链接：
[*]关于 Attribute Field 和 Text Field[*]关于 Project Settings 和 Filter Settings[*]关于 Multiple Translation（Project Settings 导致 Multipel Translation 的说明）[*]Project and Filter Settings 对话框[*]General 选项卡（续）（有关 Textv/Attribute 的说明）[*]Penalties 选项卡（有关 Attribute and text field differences penalty ％ 的说明）
对于最简单的翻译流程，只涉及到翻译和校对两类人员，在实际操作中，他（她）们都要使用 TM 来工作。对于完全由内部人员完成的翻译项目，不同的本地化公司对于 TM 的使用有不同的方案，其各有利弊：
[*]有的公司规定翻译人员和校对人员使用同一个 TM，这种方案的优点是，校对人员的校对结果可以即时地为翻译人员所用，但其缺点也十分明显，由于在校对之前，所要校对的文档的翻译单元都已存在于 TM 中，因此，校对人员需要通过查看 TU 的 Changed by 信息来确定哪些是校对过的内容，而哪些是尚未校对的内容，而且无法使用Translated to fuzzy 按钮（http://bbs.giltworld.com/UploadFile/2007-1/200714026037427.jpg）来加快校对速度；[*]还有一些公司规定，翻译人员和校对人员使用同一 TM 的两个不同拷贝来工作，这样，校对人员在工作时，只要校对过的内容都是 100％ match，因此非常容易区分哪些翻译单元已校对过，而哪些尚未校对，其缺点就是校对人员校对过的内容无法通过 TM 即时为翻译人员所用。在此，我们探讨一个解决方案，使得校对人员即容易识别校对过的内容，又可以使校对过的内容即时为翻译人员所用。为此，我们首先明确以下内容：
1、通过 Attribute 字段和 Text 字段定义 TU 的标记信息，并在 Project Settings 中进行指定，可以在提交 TU 时把 Project Setttings 中指定的 Attribute 和 Text 字段信息附加到 TU（请参阅“Project and Filter Settings 对话框”） 2、通过在 Filter Settings 中指定 Attribute 和 Text 字段信息，可以将其作为筛选条件，从 TM 中筛选带有该字段信息的 TU。筛选的实质过程是，通过设置 Penalties 选项卡（Options －> Translation Memory Optons...）中的 Attribute and text fields difference penalty 选项，对 TM 中不符合 Filter Settings 设置的 TU 的匹配率扣减 penalty 选项指定的分值，相对提高符合 Filter Settings 设置的 TU 的匹配率，从而可以在 Workbench 窗口优先显示后者。（请参阅“Project and Filter Settings 对话框”）
3、在翻译过程中，对于某句原文，如果 TM 存在完全匹配的 TU，并且当前 Project Settings 中的设置与该 TU 的标记信息不同（且不属于其子集），您没有使用匹配的 TU 所包含的译文而是对其进行了修改然后提交，这种情况下就会将其添加为一个新的 TU，并按 Project Settings 中的设置附加标记信息。这时 TM 中存在两个 Source Segment（原英文）相同但 Target Segment（译文）不同且标记信息也不相同的翻译单元，这种现象称为 Multiple Translation。（请参阅“General 选项卡（续）”）
4、General 选项卡（Options －> Translation Memory Optons...）中有一个 Do not create new translation units if only text fields differ 选项，选中该选项后，对于 3 中所述的情况，如果只是 Text 字段不同，则不创建新的翻译单元。而是使用修改后的译文覆盖 TM 中原翻译单元的译文部分（Target Segment）。
首先我们解决第一个问题：如何使校对人员容易区分校对过的内容：
要使校对结果即时为翻译所用，最直接的办法就是使用同一个 TM，但由文章开头的分析可知，这种方案的弊端就是校对人员不好区分校对过的内容。但以上的说明 2 给我们以启示，那就是虽然翻译人员和校对人员共享同一个 TM 库，但可以让他们设置不同的 Project Settings（或者只有校对人员设置 Projcet Settings），这样，由校对人员提交的 TU 就可以附加上与翻译人员不同的 Project Settings，同时，让校对人员在其 Filter Settings 中指定与其 Projcet Settings 一样的设置，这样，凡是由校对人员校对过的 TU，当在文档中再次出现时，由于其 TU 所附带的标记与校对人员的 Filter Settings 一致，因此结果为 100％ 匹配而不会扣减匹配率，而凡是由翻译人员提交但没有校对过的 TU，其标记与校对人员的 Filter Settings 不一致，因此会扣减匹配率，使最终的匹配率低于 100％，这样校对人员就可以判断，凡是 100％ match 的内容，都是校对过的内容，否则，就是需要校对的内容。
接着，我们解决第二个问题：如何使校对内容即时为翻译人员所用：
看到此处，你也许会感到不解，这个问题不是通过共享 TM 就可以解决吗？确实可以解决，但在具体操作中存在一个不大不小的技术问题。我们先分析一下校对人员如何是如何校对的。在校对翻译内容时，会产生两种校对结果：“认可翻译人员的翻译结果”、“修改了翻译人员的翻译结果”。如果校对人员设置了与翻译人员不同的 Project Settings，对于第一种校对结果，提交后，不产生新的翻译单元；对于第二种校对结果，提交后会将修改后的内容保存为新的翻译单元（如以上说明 3 所述），即出现了所谓的 Multiple Translation。对于第二种结果，翻译人员将会面临困境，因为他（她）需要从中区分哪个是校对过的，然后再使用校对后的翻译内容，而这会在一定程度上影响翻译人员的效率。也许你会想到让翻译人员也设置与校对人员相同的 Filter Settings，但这样做的结果是，对于他自己提交到 TM 中但尚未校对的内容，匹配率会由于扣减而低于 100％，而我们希望这种情况他能够顺利地重用自己提交的翻译单元，因此这个方法不太可取。
实际上，校对人员在修改翻译人员的翻译内容而后提交时，如果能够覆盖原有的内容，而不是生成新的 TU 从而导致 Multiple Transltion，则问题迎刃而解。巧合的是，这就是 Do not create new translation units if only text fields differ 选项的用武之地。使用该选项，如果匹配的 TU 的标记信息与当前 Project Settings 设置只是在 Text 字段上存在差异，修改翻译内容并提交，则不会添加新的 TU 而是覆盖原有的 TU，因此我们规定校对人员设置 Text 字段而非 Attribute 字段即可解决问题。
具体的方案如下：
首先，项目经理使用独占方式打开共享的 TM 库，在 File －> Setup －> Fields 选项卡中定义一个 Text 字段“Status”，然后规定相关人员进行如下设置
校对人员的设置 ——
1、在 Project Settings 和 Filter Settings 中设置 Status 字段，在 Text field content 中输入 approved。
2、确保 Penalties 选项卡（Options －> Translation Memory Optons...）的 Attribute and text fields difference penalty 选项的值大于零（默认值为 2）。
3、在 General 选项卡（Options －> Translation Memory Optons...）中选中 Do not create new translation units if only text fields differ。
翻译人员的设置 ——
翻译人员不要设置任何 Filter settings，最好也不要设置 Project Settings，如果设置 Project Settings，也不要像校对人员一样设置 Status: Approved。目的是只有校对人员提交的翻译单元才会标记 Status:Approved。
进行这样的设置以后，如果校对人员和翻译人员对于同伴足够信任，可以使用 Translate to fuzzy 键来加快工作速度，对于翻译人员而言，即可以快速重用自己或其他翻译人员翻译提交的但没有校对的 TU，也可以重用校对过的 TU；对于校对人员，当遇到未校对过的翻译内容或者与校对人员已提交的结果不符的翻译内容时，会停止处理，等待校对进行修改。
该方案的适用前提：
1、翻译人员和校对人员的工作需要同步进行或者存在交叉 2、项目开始时使用全新（空）的 TM 库
3、翻译人员（可以多人）和校对人员（可以多人）共用一个 TM
该方案的不足之处：
1、这种方法有一个弊端。如果校对人员修改了某个句子（Sentence A）的句式并提交，但下文中出现了类似的句子（Sentence B），且 Sentence B 相对 Sentence A 的文本匹配率为 85％。假设当前 Attribute and text fields difference penalty 设置为 2，此时我们计算 Sentence B 在 TM 中的匹配率。Sentence B 在 TM 中有两个与其最相关的翻译单元：由校对修改并标注了 Status: Approved 的 Sentence A 对应的翻译单元（Unit A）、由翻译人员提交的 Sentence B 所对应的翻译单元（Unit B），按照 Attribute and text fields difference penalty 设置和上文 85％ 的假设，Unit A 的匹配率为 85％，而 Unit B 的匹配率为 98％（100％ － 2％），因此在 Workbench 中会优先显示 Unit B。这样校对需要手动选择来参考 Unit A 的翻译，如果 Sentence A 和 Sentence B 校对的间隔时间较长，或由不同的校对人员来校对，则无法保证句式的统一。一个勉强的补救措施是，将 Attribute and text fields difference penalty 设置的足够大，但最多也只能设置到 20％。
2、与一般的翻译、校对方案一样，此方案的存在的问题是，使用 http://bbs.giltworld.com/UploadFile/2007-1/200714026037427.jpg 键保证了翻译和校对人员工作的流畅性，但是，其前提是，翻译人员高度信任校对人员，校对人员之间也互相信任，也就是说使用 http://bbs.giltworld.com/UploadFile/2007-1/200714026037427.jpg 键，翻译人员不易发现校对人员的错误，而校对人员之间也不易相互发现所存在的错误。
3、任何方案的不足都可由人来弥补，人的主动性也会提高执行效率。比如校对过程中可以将某些修改过的术语记录下来，及时发送给翻译人员进行修改，并在校对结束前进行统改。翻译人员如果发现校对人员的错误，或者校对人员之间发现了对方的错误，可以通过某种方式互相告知，并进行修正，这些都可以通过填表等交互方式来实现。但是，这类工作都是不可量化的东西，无法具体要求，也无法具体衡量其中的工作量，因此，需要靠激励机制来提高人的主动性，而人的主动性又源自哪里呢？这值得管理人员思考。
有关 DTD Setting (ini) 文件使用方面的一些问题
1、什么是 DTD Setting 文件？
2、在将某个文档显示为 TTX 文件时 Tageditor 如何确定使用哪个 ini 文件？
3、使用 Tageditor 打开 ttx 文件时是如何选择 ini 文件的？
4、在打开 TTX 文件时，如果所使用的 ini 文件与生成该 TTX 文件时使用的 ini 文件不同，是否会影响现有 TTX 文件的格式？
5、为什么每次在 Tageditor 中打开 HTML 文件，总要显示对话框，提示选择 ini？
6、我已经将某个 ini 文件从 Manager 中移除，为什么打开某个 TTX 文件后，发现该 ini 文件又被加载到 Manager 中？
7、在进行 Analyse（字数分析）、Translate（预翻译）和 Cleanup（清除原文）时需要 ini 文件吗？
8、在 Workbench 打开的 Manager 与在 Tageditor 中打开的 Manager 是同一个 Manager 吗？
9、在进行Analyse（字数分析）和 Translate（预翻译）处理时，Workbench 如何选择 ini 文件？
10、校对人员在打开 TTX 文件时，总是会弹出要求指定 ini 文件的对话框，怎样解决？
11、在项目中如何正确地使用 ini 文件？
－、什么是 DTD Setting 文件？
首先说一下什么是 DTD。DTD 文件，即“文档类型定义”(Document Type Definition) 文件，用于定义 HTML、XML 等标记语言文件应该遵循的结构、使用的元素以及语法规范。在使用文本编辑器打开 HTML 文件时，所看到的那些在浏览器中不显示的内容就是所谓的文档元素，这些元素用于定义文档的结构以及文本或其他对象在浏览器中的显示样式，它们需要遵循相应的语法规范，DTD 文件就是定义这些内容的文件。不同类型的标记语言文件的结构和所包含的元素存在差异，也就会对应有不同的 DTD 文件。
在翻译标记语言文件时，这些用于定义文件结构和显示样式的元素一般来说是无需翻译的，因此在翻译这类文件时，首先就需要将无需翻译的内容与可翻译的内容区别开来，Tageditor 编辑器一个主要的作用就在于此。它使用所谓的 DTD Setting 文件（即 ini 文件）来区分标记语言文件中可翻译内容和不可翻译内容，在 Tageditor 中打开 HTML 文件时，可以看到文件中的内容被处理为三种形式，即灰色的外部 tag、红色的内部 tag，以及可翻译的文本内容，这个就是使用 ini 文件的处理结果，而这些变成 tag 的内容，就是标记语言的元素，如下所示：
http://bbs.giltworld.com/UploadFile/2007-4/200742013553481413.jpg（INI_1）也就是说，ini 文件区分标记语言文件中的元素和文本内容，并进一步区分要处理为外部 tag 的元素和要处理为内部 tag 的元素，前者一般定义文档结构（比如段落标记）；后者一般定义显示样式（比如字体）。另外，ini 文件还确定对于一些非 ASCII 字符的处理方式，这些字符称为“实体”（entity），比如对于商标符号，是处理为红色的 tag 占位符，还是将其转换为实际的字符。总之，ini 文件就是用于将标记语言文件转换为 Tageditor 可编辑的包含外部和内部 tag 以及文本内容的 ttx 文件。
不同类型的标记语言文件对应不同的 ini 文件，比如对于 HTML 文件和 XML 文件会使用不同的 ini 文件。Trados 6.5 自带了几个 ini 文件，比如用于处理 HTML 文件的 HTML4.ini 以及用于处理 XML 文件的 XSL.ini。可以修改这些 ini 文件来定义自己的 ini 文件，因此来说，同一类型的标记语言文件可以使用不同的 ini 文件来处理，当然，不同的 ini 文件对于元素的处理可能会存在差异，对于某一个元素，可能会将其处理为内部 tag，也可能会处理为外部 tag，具体取决于所使用的 ini 文件中的设定；再比如上面提到的商标符号实体的处理，在有的 Tageditor 版本中，无法正确显示实际的商标符号，而是显示为一个问号（?）,通过修改 ini 文件，可以让其不将商标符号转换为实际的字符，而是处理为内部 tag 占位符，这样在翻译后生成的文档中，商标符号就可以正确显示。有关 ini 文件的这些内容，将辟专文介绍，此处不再赘述。
二、在将某个文档显示为 ttx 文件时 Tageditor 如何确定使用哪个 ini 文件？
打开 Tageditor 的 DTD Setting Manager（Tools －> DTD Settings），可以看到当前可以使用的 ini 文件：
http://bbs.giltworld.com/UploadFile/2007-4/20074201359243111.jpg（INI_2）
其中的 Descriptive Name 是 ini 文件的描述性名称，DOCTYPE 是 ini 文件的适用类型，File Name 是 ini 文件的存放路径。“问题一”中提到，不同类型的标记语言文件（比如 HTML 和 XML）需要不同的 ini 文件来处理，DOCTYPE 就是区分所适用的文件类型的，比如 HTML4.ini 文件的 DOCTYPE 为 HTML，表示它可以处理 HTML 文档，可以说，任何 DOCTYPE 参数值为 HTML 的 ini 文件，原则上都可以处理 HTML 文件，而这些可以处理同一类型标记语言文件的 ini 之间则使用 Descriptive Name 来区分。
一般来说，在标准的 HTML 文件和 XML 文件的文档类型声明中，都会有一个所谓的 Root Element（根元素），它一般位于文档的开始部分，代表文档的类型，比如，标准的 HTML 文件的“根元素”如下所示：
http://bbs.giltworld.com/UploadFile/2007-4/20074201412953121.jpg
XML 文件的“根元素”的示例如下所示：
http://bbs.giltworld.com/UploadFile/2007-4/20074201422556675.jpg(INI_4)使用 Tageditor 打开 HTML 或 XML 等文档时，Tageditor 将被打开的文档的“根元素”与 DTD Setting Manager 中列出的各个 ini 文件的 DOCTYPE 部分比较，如果有匹配的 ini 文件，则会使用这个 ini 文件将被打开的文件显示为 TTX 文件，此时打开 Manager 会发现，当前使用的 ini 标注了红色的对勾。
如果 Manager 中有多个 ini 文件的 DOCTYPE 与该文档的“根元素”匹配，则会弹出以下对话框，提示从中选择一个 ini 文件，例如在打开 HTML 文件时可能显示以下对话框：
http://bbs.giltworld.com/UploadFile/2007-4/20074201492248558.jpg（INI_5）如果没有匹配的 ini 文件，则会提示指定一个 ini 文件：
http://bbs.giltworld.com/UploadFile/2007-4/200742014364153318.jpg（INI_6）当保存 TTX 文件时，会将 ini 文件的 Descriptive Name（描述名称）信息和所使用的 ini 文件的路径记录到 TTX 文件顶部的 Trados 声明信息中，其中，ini 文件路径保存在 SettingsPath 参数中，而 Descriptive Name 保存在 SettingsName 参数中，如下所示：
http://bbs.giltworld.com/UploadFile/2007-4/20074201412333612.jpg（INI_7）下次打开 TTX 文件时，将使用这个信息自动寻找相应的 ini 文件。
三、使用 Tageditor 打开 TTX 文件时是如何选择 ini 文件的？
如以上问题所示，在保存 TTX 文件时会写入所使用的 ini 文件的信息。下次打开 TTX 文件时，会按以下步骤寻找 ini 文件：
[*]按照 TTX 文件中 SettingsPath 参数标注的路径确定 Manager 中是否有该 ini 文件[*]如果有会比较 TTX 文件中的 SettingsName 参数是否与 ini 文件的 Descriptive Name 一致[*]如果一致，则使用该 ini 文件[*]如果 Manager 中不存在 SettingsPath 参数对应的 ini 文件，则会按路径检测该文件在系统中是否存在[*]如果存在且其 Descriptive Name 与 SettingsName 参数一致，则将其加载在 Manager 中并使用[*]如果该 ini 文件不存在或者存在但 Descriptive Name 与 SettingsName 参数不一致，则会查找 Manager 中是否有其他 Descriptive Name 匹配的 ini[*]如果有则默认使用该 ini 文件，否则显示以下对话框，提示添加 ini 文件：http://bbs.giltworld.com/UploadFile/2007-4/200742014131412573.jpg（INI_8）Tageditor 选择 ini 文件时的处理流程如下，此流程是笔者的经验总结，不保证绝对准确，仅供参考：
http://bbs.giltworld.com/UploadFile/2007-4/200742014142891643.jpg（INI_9）四、在打开 TTX 文件时，如果使用的 ini 文件与生成该 TTX 文件时使用的 ini 文件不同，是否会影响现有 TTX 文件的格式？
不会影响，即使使用用于 XML 的 ini 文件打开由 HTML 转成的 ttx 文件，也不会改变原有格式。我们可以用记事本打开 TTX 文件，其中的一段内容如下所示：
http://bbs.giltworld.com/UploadFile/2007-4/200742014153415694.jpg（INI_10）可以看到使用 <ut ....</ut> 标注的部分在 Tageditor 中显示为 tag，而 <ut ....</ut> 中标注了 Style="external" 的会显示为外部 tag。也就是说在使用 ini 将 HTML 等文件转成 TTX 文件时，实际上就是加入这些标注，而在打开 TTX 文件，ini 文件并不起作用，Tageditor 只是按照原有的标注进行显示，而不会按照当前选择的 ini 文件形成新格式的 TTX 文件。
但是，当保存该 TTX 文件时，会将当前选择的 ini 的信息写入 TTX 文件，而这个 ini 文件并不一定与最初使用的 ini 文件一致。
五、为什么每次在 Tageditor 中打开 HTML 文件，总要显示以下对话框，提示选择 ini？
http://bbs.giltworld.com/UploadFile/2007-4/20074201492248558.jpg（INI_11）这是因为 Manager 中存在多个 DOCTYPE 为 HTML 的文件，根据项目需要保留其中的一个 ini，将其他移除，下次就不会询问，而直接使用保留的那个 ini 文件打开 HTML 文件。
六、我已经将某个 ini 文件从 Manager 中移除，为什么打开某个 TTX 文件后，发现该 ini 文件又被加载到 Manager 中？
对于由 HTML 或 XML 等文件转成的 TTX 文件，其中会保存所使用的 ini 文件的信息，具体来说，会在SettingsPath 参数中保存 ini 文件的路径，在 SettingName 参数中保存 ini 文件的 Descriptive Name。打开 TTX 时，会按照这些信息，查找上次使用的 ini 文件，如果找到且 SettingName 与该 ini 文件的Descriptive Name 匹配，则会使用该 ini 文件，即使它不在 Manager 中，也会将其加载进来。另请参见问题 三。
七、在进行 Analyse（字数分析）、Translate（预翻译）和 Cleanup（清除原文）时需要 ini 文件吗？
ini 文件只应用于 HTML 或 XML 等标记语言文件。在对此类文件进行 Analyse 和 Translate 时，需要使用 ini 文件，而其他格式的文件（如 RTF）则不需要。另外，实践经验表明，进行 Cleanup 时似乎不需要使用 ini 文件，还有待确认。
八、在 Workbench 打开的 Manager 与在 Tageditor 中打开的 Manager 是同一个 Manager 吗？
Trados Workbench 的 DTD 在如下位置设置：Options > Translation Memory Options > Tools。应该说，通过 Workbench 打开的 Manager（简称 Mananger1）与通过 Tageditor 打开的 Manager（简称 Manager2）即相互关联又有所区别。一般在打开 Workbench 时，其 Manager1 的设置与 Manager2 中的一致，而且如果修改了 Manager2 的设置，则下次启动 Workbench 时，Manager1 也会随之而改变。一般来说，Manager 1 用于 Analyse（字数分析）、Translate（预翻译）和 Cleanup（清除原文）等批处理操作，进行批处理前，可在上述三个对话框中选择 Option－>Translation Memory Options，点击 DTD Settings 来修改 Manager1；而 Manager2 用于对在 Tageditor 中打开的标记语言文件进行格式处理，将其转成 TTX 文件。
九、在进行 Analyse（字数分析）和 Translate（预翻译）处理时，Workbench 如何选择 ini 文件？
批处理中选择 ini 的原则与在 Tageditor 中选择 ini 的原则 一致，即所选择的 ini 文件，其 DOCTYPE 应与要处理的文件的 Root Element 一致。
列表中可能会包含多种类型的 ini 文件，也可能包含多个同一类型的 ini 文件，具体的选择规则如下：
①从 DTD Settings Manager 列表中选择适用的 ini 文件，如果同时有多个 ini 文件适用，则使用第一个 ini 文件；
②如果没有适用的 ini 文件，则使用已设置的默认 ini 文件；
③如果即没有适用的 ini 文件，也没有默认的 ini 文件，或者列表中没有任何 ini 文件，则跳过处理文件，同时在 Log 中写入错误消息。
因此，在对标记语言文件进行批量处理时，应检查 Workbench 中的 DTD Settings Manager 列表，确保存在要使用的 ini 文件，如果有多个适用的 ini 文件，应确保要使用的 ini 文件在列表中位于其他适用的 ini 文件之前。对话框中没有提供调整 ini 文件顺序的按钮，如需要，可通过 Add 和 Remove 按钮间接调整或将不需要的其他 ini 暂时移除（不会将实际的 ini 文件删除）。
十、 校对人员在打开 TTX 文件时，总是会弹出要求指定 ini 文件的对话框，怎样解决？
有关打开 TTX 文件时 Tageditor 如何选择 ini 文件，请参见“问题三”的解答。
以下情况可能会导致出现此类问题：
[*]翻译人员使用的 ini 文件正确，但校对的 Manager 中没有同一 ini 文件、也没有其他匹配的 ini，并且翻译人员所用的 ini 所在的路径与校对人员的不同（如果校对人员的机器上存在该 ini 文件）。请参加问题三[*]翻译人员使用了错误的 ini 文件解决办法：
[*]校对人员在 Manager 中添加要使用的 ini 文件[*]提示翻译人员使用正确的 ini 文件（以上提到的翻译人员和校对人员仅是使用常规的翻译流程来举例说明，所述内容并不仅限于文中所列情况，比如有的客户会提供生成后的 TTX 文件，或者由 PM 生成 TTX 文件，而不是由第一手的翻译人员来生成 TTX 文件。）
十一、在项目中如何正确地使用 ini 文件？
[*]首先要根据客户需求明确所要使用的 ini 是 Trados 默认的 ini 文件，还是客户指定的 ini 文件[*]执行 Analyse 或 Translate 时，会默认使用第一个合适的 ini 文件，因此，应确保要使用的 ini 文件在 Manager 列表中位于其他适用的 ini 之前。比如要对 HTML 文件进行分析或预翻译，如果 Manager（在 Workbench 中通过 Options > Translation Memory Options > Tools 来访问）中有多个适用于 HTML 文件的 ini 文件，请确保要使用的 ini 文件位于其他适用的 ini 文件的上方，或者将其他适用的 ini 文件暂时移除[*]在翻译标记语言文档前最好将其他同类 ini 文件移除，只保留要使用的 ini 文件，比如翻译 HTML 文档，如果客户提供了 ini 文件，最好将此 ini 文件添加到 Manager，并将其他用于 HTML 的 ini 文件暂时移除，这样在翻译和校对时就不会弹出对话框来要求选择 ini 文件。[*]项目结束前可对 ini 的使用情况进行检查，方法是使用 Search and Replace 都一类的工具在包含所有 TTX 文件的目录中查找字符串：SettingsName="xxxxxx"，其中 xxxxxx 为要求使用的 ini 文件的 Descriptive Name（描述名称）。如果搜索到的匹配数与文件数相同，则可大致认为没有 ini 使用错误。
关于 Analyse 选项卡的一点使用体会
一、当与客户的字数分析结果不一致时，怎样查找原因：
作为 PM，常常需要与客户或 Vendor 核对字数分析结果，当双方的分析结果存在差异时，怎么来排除原因？以下结合本贴第 77 楼的内容“字数分析（Analyse）的影响因素”来给出一些个人建议，仅供参考：
假定手边有客户或 Vendor 的 log 文件及您自己的 log 文件。下面分 5 个步骤来查找原因：
1、确认双方使用的 TM 是否一致。log 文件分析报告的第二行会列出生成该报告时所用 TM 的本地路径，可以核对两个报告的 TM 文件名来简单确认是否一致。当然，最好双方通过沟通进行确认。如果一致，则进行第二步；
2、查看 log 报告结尾处所有文件汇总结果中 Total 行的内容（以下统计结果如无特殊说明，均指 Total 行的内容），确认两个 log 中 Total 行的 Words 值是否一致。如果不一致，若分析的是需要使用 ini 文件的标记语言文件（如 html、xml，等等），则有可能是双方使用的 ini 不一致，这时可以进一步查看 Total 行中 Placeables 值是否一致，不一致的话可以基本确认是 ini 问题；对于 rtf 文档很少会出现这一情况，当然，如果在 workbench 中设置了Non-translatable，也可能会引发这一问题，请参阅“字数分析（Analyse）的影响因素”中的“一、确定可翻译的内容”。如果两个报告中 Total 行的 Words 和 Placeables 值一致；则进行第三步；
3、查看 Total 行的 Segments 值是否一致，如果不一致，则可能双方所使用的 TM 的“翻译单元划分规则”（File > Setup > Segmentations rules）存在差异。一般来说，这个规则是随 TM 保存的，而不是保存在本地 Trados 的注册表中，因此，双方使用同一 TM 拷贝时不会出现这种情况，除非有一方人为进行了修改。相关内容请参阅“字数分析（Analyse）的影响因素”中的“二、对可翻译内容划分翻译单元（TU）”。如果 Total 行的 Segments 一致，则进行第四步；
4、查看 100% 和 95% - 99% 行是否存在差异，如果这两行存在差异，但其他行的统计结果一致，则可能是 Filter Settings 设置或 Penalties 设置存在差异。请参阅“字数分析（Analyse）的影响因素”中的“三、与 TM 中的 TU 进行匹配”。如果这两行一致，请进行第五步；
5、如果以上内容均一致，但 Total 行的 No Match 值不一致，那就极有可能是双方所使用的 Workbench 中的 Minimum match value % 设置（Options > Translation Memory Options > General 选项卡）不一致。请参阅“字数分析（Analyse）的影响因素”中的“四、统计匹配结果”。
如果以上所有步骤均无法找到问题缘由，我也就黔驴技穷了。http://bbs.giltworld.com/images/emot/em09.gif
二、使用 Analyse 分析多个文件时，文件的顺序问题：
在分析多个文件时，我们通常是先打开 Analyse 对话框，然后在文件夹中选中所有要分析的文件，再用鼠标将文件一次性拖放到 Analyse 对话框的“Files to analyse:”列表中。但这样做会有一个问题，即拖放到对话框中的文件路径常常不是按其在文件夹中的顺序来排列。比如下面的示例，左边目录中的 ttx 文件是按名称顺序排列，但全选拖到列表中后顺序被打乱了，而且分析后所生出的 log 报告（包括 csv 格式的报告）也是按这一顺序排列的：
http://bbs.giltworld.com/UploadFile/2007-8/20078282346148366.jpgAA-1（文件夹目录）http://bbs.giltworld.com/UploadFile/2007-8/200782823462737135.jpgAA-2（Analyse 对话框的 Files to Analyse 列表）
观察上图，虽然列表中的文件名顺序被打乱了，但还是有规律的，比如这里是 4、5、6、1、2、3。其实，这与拖动文件时鼠标的点击位置有关。在将多个文件拖放到列表时，默认将鼠标点击位置处的文件列为第一个文件，然后该文件后续的文件依次排列，到末尾后，转为从选中的第一个文件继续排列，直到所有文件排列完毕。比如 4、5、6、1、2、3 这个顺序，就是执行拖放操作时，鼠标点击在文件 4.htm.ttx 上的结果。所以，拖放操作时，让鼠标点击选中的第一个文件，这样列表中的文件顺序就与目录中的一致了。在使用播放器通过拖放操作连续播放多首 mp3 时也是这个道理。
三、Analyse 功能对翻译人员有哪些用处：
1、翻译人员可以使用 Analyse 来核对自己的工作量；
2、翻译人员在翻译过程中可以随时使用 Analyse 来大致估算自己的工作进度。分析结果中非 100％（fuzzy match 和 no match）部分即为翻译尚未完成的工作量；
3、翻译结束后，检查是否有漏翻的情况：
使用 Analyse 分析所有文件，理想情况下，如果没有漏翻的情况，且所有翻译内容均已存入 TM，所有内容应为 100% 匹配。但也会由于 Filter Settings 设置或 Penalties 设置而存在部分 95% - 99% 的匹配内容。但是，如果除 95% - 99% 之外的 Fuzzy match 部分或 No match 部分也存在统计结果，则说明有漏翻的情况。对于漏翻的情况，可通过以下两种方式快速定位： a、如果所翻译的文件较少或单个文件非常大，在分析结束后，可以使用对话框底部的 Export Unknown Segments..... 按钮并设置相应的匹配率，将未翻译的内容导出到 rtf 文件，然后再对照这个 rtf 文件逐一查找翻译文件；
b、如果所翻译的文件较多，可以利用 CSV 格式的 log 报告来定位。打开 log 报告，按包含漏翻内容的相应匹配率排序，即可确定漏翻内容所在的文件。打开漏翻内容所在的文件后，打开第一个翻译单元，然后直接按 Translation to fuzzy 定位漏翻内容。
好详细。。。。楼主辛苦了。
