大家好！
我叫Denisov Alexander。 我为Naumen工作，负责记录和本地化Naumen联络中心（NCC）软件产品。
在本文中，我将讨论在英语和德语本地化NCC时遇到的问题以及如何解决这些问题。 当然，今天我们还不能解决所有任务，而且很可能这个过程是无止境的。 本文考虑了整个过程的远景，以及我们尝试遵守或开始应用的那些原则。 对于刚开始设计软件，计划对其进行本地化或已经面临问题但还不知道如何解决问题的人员，本材料将非常有用。
引言
当产品准备就绪并为其编写文档时，公司通常会考虑软件本地化。 而且，为了在短时间内获得良好的本地化而又不花费大量资源，做某事通常为时已晚。
不可能在一篇文章中详细介绍所有问题和困难，因此，我将简要介绍文档编制和本地化的主要阶段，并就我认为最重要的几个问题进行探讨：
- 软件开发生命周期的哪些阶段会影响文档和本地化的质量？
- 在每个阶段什么时候做什么？
- 工具的哪些方法，功能可用于解决每个阶段的问题？
- 像组织。 结构会影响文档和本地化吗？
- 如何组织接收文档用户的反馈？
- 如何在每个阶段节省时间和财务成本？
根据我在NCC记录和本地化方面的多年经验，我将尝试回答这些问题。
NCC的特点和发展历程
Naumen联络中心是用于组织大型公司或外包联络中心的复杂软件。
记录和本地化此系统有什么困难：
- 系统不多云。
- 复杂的设置，与各种系统的许多集成。
- 支持多个版本。
- 由于第1-3段，我们进行了复杂的实现和更新。 每个客户端都有自己的版本，自己的配置以及与各种系统的集成。
- 该系统规模不大；仅由大型企业使用。 因此，与小批量产品相比，客户数量不是很大。
- 大量的特定术语。
- 多角色模型。 这意味着必须根据每个角色的特征（知识水平和任务特征）量身定制文档和界面。
- 系统界面包含约30,000行文本，并编写了约3,000页复杂的技术文档。
- 发行版每年发行2-3次。
- 每次发行后，约有10％的界面文本和文档得到更新和补充。
- 3种语言：俄语（源），英语和德语。
开发生命周期
让我们看一下软件开发的生命周期，仅选择与文档和本地化有关的那些阶段：
- 功能开发。 作为此阶段的一部分，将开发界面文本。
- 文献资料 作为此阶段的一部分，将开发文档，包括创建屏幕截图和其他图像。
- 接口以几种语言本地化。
- 将文档翻译成其他语言，包括屏幕截图和其他图像的本地化。
现在，让我们想象一下在界面中犯了一个小错误。 它自动适用于每个阶段，适用于多种版本和语言。
其他错误可能会出现在每个阶段，也就是说，我们可能会收到大量错误。 较小的接口错误很可能永远不会得到修复；总会有更重要的任务。 而且，如果您进行编辑，那么这些编辑的成本将非常高，因为您将不得不遍历整个链，所有版本和语言。 版本和语言越多，价格就越高。
在这种情况下，不能只谈论界面本地化的质量或翻译文档的质量，因为每个阶段的工作结果都是下一阶段的基础。 这就是为什么在每个阶段立即做所有事情非常重要。 这就是为什么值得将软件开发，文档编制和本地化视为单个不可分割的过程的阶段的原因。
界面中的文本组织
当我们的程序员着手进行系统本地化时，它绝对还没有为此做好准备。 接口的文本存储在代码中，管理的愿望是：“快速完成所有工作”。 程序员编写了一个脚本，该脚本从代码中提取了所有文本并将其扔到资源文件中，第二天，他们将资源文件交给了第一位会英语的员工，后者很快在记事本中翻译了所有内容。 这可以从下面看到。
该图显示了一个简单的按钮，它打开了一些带有参数的表格，可以在其中更改这些参数。 系统中有数十个这样的按钮。 在俄语中，此按钮有3个选项；本地化为英语已经包含7个选项。
在这种情况下，迫切需要清理接口的线路。 为此，我建议应用以下规则：
- 将所有行划分为组。
根据接口元素的类型，应将所有行分为几组。 即使这些行具有相同的文本，不同的翻译规则也可能适用于不同的组。 例如，英语中每个单词的第一个字母的大写规则。 对于某些类型的界面元素，不使用它。 - 删除重复项。
在每个组中，删除所有重复的行（即具有相同文本的行）是有意义的。 然后将只有俄语和其他语言的唯一选择。 这样可以节省翻译成本。 我注意到重复的行很可能仍会保留，因为在某些情况下上下文可能有所不同。 此外，具有相同源文本的这些行可以以不同的方式翻译。 例如，在人名的上下文中， 名称一词可以翻译为名字 ，在文件名的上下文中，可以简称为Name 。 - 向行标识符添加上下文。
线路标识符可以包括线路本身的标识符以及该线路所属的组。 这是必需的，以便翻译器可以使用标识符来选择本地化规则。 如果我们有这样正确的标识符，那么检查和更正相同大小写错误的过程就可以轻松实现自动化。
不幸的是，一次将这些规则应用于所有现有的30,000行非常耗时。 在这里，我们处于起步阶段，并逐步整理最频繁重复的行并为新行制定规则。 但是您必须承认，如果所有规则都立即阐明并实施，那就太好了！
文档和本地化流程
让我们看一下基于时间的文档和本地化过程。 如果在功能开发完成之前开始记录和本地化，则您将必须重做所有内容（可能要重做几次）。
翻译文档也一样。
而且，如果您在所有编辑结束之前将文档提供给用户，则可以指望一堆注释。 这些注释中的一些很可能会在开发的最后阶段得到纠正，但是您将不得不花费额外的时间来处理它们。
如果流程不协调，并且我们没有按时跟踪所有更改，那么“无处无处”将不对应。
该文档将与界面不匹配。 屏幕截图与界面和文档文本不匹配。
本地化也一样。 源语言中的界面和文档的文本与其他语言中的界面和文档的文本不匹配。
我们决定，目前只有在完成上一个阶段后，我们才能开始每个阶段。
是的，我们的文档和本地化版本在发布后很晚才发布。 谈到本地化，我们已经确保了进行连续本地化的可能性，但是我们没有利用这个机会，而是在发行结束时一步就完成了所有本地化。 作为半年发布的一部分，几天是一个很小的阶段。
只要我们的产品不是很大，我们就没有迫切需要在同一天出现文档和本地化信息。 我们拥有长期发布的大型企业客户，与小型和大型产品相比，它们的数量并不多，并且他们不会立即开始安装该产品的新版本或对其进行升级。 不断改造的成本明显降低。
术语问题
在文档和本地化阶段，我们经常遇到术语方面的问题：
- 相同实体的名称不同，不同实体的名称相同。
- 相同的术语以不同的方式翻译，不同的术语以相同的方式翻译。
- 一个实体可以与其组成的子实体或父实体等同。
- 选择了不成功或不正确的术语来表示实体。
在一段时间内，我们的开发过程如下所示：
- 分析师正在撰写作品。
- 测试人员测试产品。
- 开发人员代码。
- 测试人员测试结果。
当尝试使用术语进入这个过程时，我们得到了这样的借口：
- 您将减慢整个过程。
- 这通常不是那么重要。
- 您拥有工具，以后可以修复所有问题。
但是“后来”事实证明，我们无法解决所有问题。 例如，在某些情况下，由于对术语的理解不正确，系统对象被置于错误的层次结构级别或被组合为错误的组。
现在，我们在设置测试的同时检查接口的术语和文本。 也就是说，在测试人员发表评论的同时，我们也撰写自己的评论。
我们在生产测试期间的工作：
- 我们揭示新术语。
- 检查界面文本：是否正确使用术语，是否遵循样式指南以及是否符合角色。
- 我们确定现有的行，以免重复。
- 我们同意本地化的必要性，因为该界面的某些部分只能在一个国家/地区使用。
在显示新术语时，我们将它们添加到词汇表中，同时：
- 添加定义或上下文。
- 我们指出与其他术语的关系（指示父母和子女的术语）。
- 我们试图立即指出英语的含义，因为选择英语名称后，有时您会发现俄语选择不正确。
可以说，由于在批准设置阶段术语和界面文本的协调，我们在随后的阶段开始节省大量时间进行多次更正。
文献资料
我们在记录时遵循的原则：
- 使用单一源系统。
- 使用词汇表。
- 使用样式指南。
- 将文档分为小文件和易于转让的文件。
即使主要格式是Web，这也是值得做的。 如有必要，您不能翻译所有文档，而只能翻译最重要的文档，或者分阶段进行翻译。
现在，我将讨论文档编制过程中一些最重要的方面。
重用文字
在大多数单源系统中，可以使用变量。 因此，我们开发了将界面资源文件自动转换为变量文件的脚本。 在开发文档的过程中，我们不键入界面元素的文本，而是在文本中插入变量。 因此，在俄语版本中，俄语行会自动拉入，而英语版本则是英语，德语是德语。
有什么好处：
- 如果在文档中提到接口元素文本中的错误，则将其排除在外。 文档中界面元素的文本始终与界面中的文本相同。
- 如果界面中的文本行已更改，则它们将在文档中自动更改。
- 翻译文档中界面元素的文本时，错误排除在外。
- 译员花费的时间更少。
文档中有很多重复的句子。 例如，一句话-“单击“
保存”按钮。 在单源系统中，可以将这样的建议放在摘要中。 代码段是如此之小，可以插入文档的其他页面。
如您所见，摘录中的“
保存”按钮的文本也从变量中替换。
这提供了以下好处：
- 含义相同的句子到处都是相同的，这意味着文本的统一性增加了。
- 通过重复使用来开发文档的成本得以降低。
- 此类句子仅翻译1次。 这降低了翻译器的成本。
屏幕截图和其他图像
在我们的文档中，我们经常使用屏幕截图和其他可能包含文本的图像。
要单独使用不同语言的屏幕截图，请在每个屏幕截图下方写上使用的文本。 该文本被标记，不会出现在完成的文档中。 翻译文档之前，我们先翻译文本以获取屏幕截图。 在文档翻译过程中，我们会在没有语言知识的情况下拍摄技术作家的屏幕截图。
使用屏幕截图，还有其他困难。 例如，如果界面更改一行文本（在50个地方使用），如何跟踪所有更改？
然后如何找到这50个地方的所有屏幕快照以在文档中替换它们？
为了解决这个问题，我们使用了在Tinkoff开发的QVisual工具。 使用它的过程如下所示：
- 在文档的开发过程中，在每个屏幕截图下方，我们都会链接到获取该屏幕截图的架子。
- 在某个时候，我们准备所有链接的列表。
- 我们将接收到的列表加载到QVisual中。
- QVisual运行该产品的一个版本，并获取一组屏幕截图。
- 接下来，我们采用该产品的新版本，并且QVisual使用相同的链接运行该产品。
- 然后，QVisual比较2组屏幕截图并生成报告。 在报告中以图形方式可以看到两个版本之间的差异。 下面是一个示例。 您可以立即看到在新版本的屏幕截图中，出现了其他字段“ 用户界面语言” 。
- 接下来，我们对每种语言重复比较过程（第1-6页）。
- 我们获取报告并浏览文档中的屏幕截图。
因此，我们减少了许多手动屏幕截图检查的成本。 而且，手动并非总是能够识别所有错误，您可以简单地忽略某些内容。
的确，不是所有的窗口都可以使用链接打开，并且这仅适用于基于Web的界面，但是仍然消除了一些更新屏幕截图的问题。
接口本地化
在本地化接口之前，如果尚未完成，则需要翻译所有词汇表术语。
翻译词汇表后，即可开始本地化。 在此过程中，我们遵循以下原则：
- 使用词汇表。
- 我们使用翻译记忆库。
- 我们使用样式指南。
- 我们使用上下文。
- 我们使用自动质量保证（QA）。
我注意到，与在翻译记忆库中拥有相同的，已翻译的行相比，上下文做出翻译决定的优先级更高。 同样，基于上下文，样式指南中指定的某些翻译规则可能适用。
提供上下文的方式有几种：
- 正如我在上面所写，上下文可以放置在字符串标识符本身或资源文件的其他字段中（如果格式允许）。
- 可以添加屏幕截图。 目前，我们可以将屏幕截图手动添加到特别复杂的行中。
- 提供源语言的展台和文档。 如实践所示，此方法无效。 翻译人员通常不使用提供给他们的材料和立场。 也许是因为翻译一行所花费的时间增加了很多倍。
文件翻译
我们在翻译文档时要遵循的原则：
- 首先，我们翻译屏幕截图和其他图像的文本。 正如我上面所写，屏幕快照与文档翻译同时进行。 这是在展台上完成的，其中使用了翻译文本作为屏幕截图。
- 我们只翻译变更和新行。 以前翻译的行具有100％的匹配度只是看不到。 是的，您可以重新阅读每个版本的所有文档，但是要考虑到每个版本大约更新了文本的10％，减去文本的剩余90％是不合理的成本。
- 使用词汇表。 在界面本地化阶段，必须提前翻译词汇表。
- 我们使用内存转换文档。
- 我们使用内存转换界面。
- 我们使用样式指南。
- 我们使用自动质量控制（QA）。
组织结构和反馈
我会说几句关于公司的组织结构。 每个人的情况都不尽相同，但请设想一下每个部门都有自己的部门的情况。
从一个部门到此版本中的上一个部门的反馈将很困难，不同部门的员工之间的交互也很困难。 通过头部解决所有问题的方法也是“缩小脖子”。 每位领导人都有自己的愿景，目标和优先事项。 很多时间可以花在其他批准上。
我认为，一个部门应对所有语言的所有文本负责。
通过这种责任分配，产品的每个版本都是一个处于多个阶段的单独项目，并且必须从整体上回答这个项目的实施质量。 建立反馈，快速理解任何问题，进行回顾并找到问题的根本原因更加容易。
我举一个例子。
由于我们的技术撰稿人本身使用质量检查来验证翻译，因此我们发现了数十个（即使不是数百个）不一致的错误。
事实证明，翻译者看到的句子含义相同，但是方式不同，因此为它们进行相同的翻译。 我们启动了任务，技术写作人员替换了同一段文字中所有相同版本的含义。 现在将不再有此类重复错误。 专业人士将不必花费时间分析它们，并且将来将其翻译成新语言将变得更加容易。
在一般情况下，如果翻译人员在翻译过程中有疑问，那么对我们来说，在早期阶段出现问题已经是“警钟”，我们需要做更正任务。
需要什么质量文件
在尝试以所有语言制作完善的文档之前，值得考虑需要什么质量？ 其他问题将有助于回答以下问题：
- 谁是文档的用户？
如果文档属于公共领域，并且客户根据文档决定购买产品，则质量应接近理想水平。 ( ), . , . , : , , . . - ?
, , . . ? , , .
如果您决定阅读文档：- 并非可以全部减去。
建立有关文档使用情况的统计信息并提交以供校对，例如，成千上万的用户阅读的前50页。如果某些页面每年阅读1-2次，则可以忽略它们。 - 最好阅读完成的文档。
在CAT系统中不能看到所有问题。例如，将图片与文本匹配或在公共文档中匹配文本的不同部分（摘要，变量），标题翻译的统一方法等。 - 除了真正借助文档解决问题的用户外，没有人会说您的文档是否高质量。
- 除了讲母语的人之外，没有人会说文档的翻译质量。
在发布之前，我们会将具有已描述功能的Web文档提供给内部使用。俄语的校对文档是由整个部门（尤其是分析人员）完成的，因为他们是负责开发任务的人员，并且在此阶段他们最了解文档中应包含的内容。新员工也是非常有价值的文档用户。初学者会焕然一新，目标是在试用期间使用该系统。合作伙伴也可以阅读翻译后的文档。您可以与他们签订此类协议。伙伴会向您发送所有评论，但同时他会理解系统。是什么让用户发送反馈：- .
- , . . , Ctrl+Enter . . . - .
, . , , . - 用户自己做。
也就是说，它们有助于自己和其他用户改进文档，并因此而感到满意。下次他们再次需要信息时（其中有错误或缺少信息），他们将在文档中找到信息，而不必自己将答案写给客户。他们只是将链接发送给联系技术支持的客户。这样，他们可以降低自己和同事的成本。
我注意到，我们仅在当前版本的文档中（即仍在开发中的文档）更正这些注释。我们认为，与花大量时间支持旧版本相比，最好是尽可能多地关注新版本，并尽可能减少错误。结论
每个公司都处于自己的发展阶段，通常不必为了获得令人满意的结果而投入大量的人力资源。首先，弄清楚目前到底需要什么，并做到这一点，并随着需求的增加而增加成本。这是一篇有关文章和本地化过程的一般文章。将来，我将尝试写一些狭窄的话题。谢谢，如果您读完了！祝您在工作和调试文档和本地化过程中取得成功！我很乐意回答问题，讨论您的想法和想法！