|
 
- UID
- 501
- 帖子
- 225
- 精华
- 3
- 积分
- 1627
- 威望
- 201
- 译币
- 991
- 阅读权限
- 70
- 性别
- 女
- 来自
- NJ
- 在线时间
- 12 小时
- 注册时间
- 2009-9-30
- 最后登录
- 2010-12-28
|
3#
发表于 2009-10-15 14:43
| 只看该作者
【专题讨论】字数分析（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 库对以下文档进行分析，该文档包含三句话，它们之间类似但并不完全相同：
（UTF-1） 首先使用空的 TM 库直接对该文档进行分析，结果如下：
（UTF-2） 然后将 Analyse 对话框关闭并重新打开（因为此时临时 TM 库已包含了这三个翻译单元），先分析一个不包含任何内容的空 RTF 文档，该文档与分析结果没有任何关系，但通过分析这个空文档就可以启用 Use TM from previous analysis 选项。分析完空文档之后（此时，临时 TM 中没有任何翻译单元），选中该选项，使用临时 TM 库分析以上文档，其结果如下：
（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 的目的。
翻译过程中使用 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 按钮（ ）来加快校对速度；
* 还有一些公司规定，翻译人员和校对人员使用同一 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）。 |
|
