Google Translate 是一个了不起的翻译引擎。 与 Microsoft、Amazon、Deepl 和其他领先的机器翻译引擎谷歌翻译一起,从统计和定性的角度来看,它们都能产生越来越好的结果。尽管我运营着一个翻译平台,但至少可以说,我在 GoogleDocs 环境中翻译文档的轻松和简单性非常诱人。 通常情况下,我是更好的人,我会抵制那种诱惑,并通过Bureau Works,我们的翻译管理系统,处理翻译。 即使我决定自己翻译,我也会利用我们定制的术语库和我们的翻译记忆库。但是一个星期三下午,我有一份很大的工作说明书需要尽快翻译,而且谷歌翻译的诱惑比我抗拒的冲动更大。 我按下按钮,就像变魔术一样,我立即翻译了文档的另一个版本。 我不得不在这里和那里修复某些误译,但整体质量出奇地好。 在对文档校对了大约一个小时后,我将其发送给我们的客户,然后我就完成了。或者我以为我完成了。接下来的一周,我们在样式和文本编辑方面对我们的模板进行了重大更改。 如果我想更新文档:
- 我要么必须再次完成整个 GoogleTranslate 过程。 只是现在,这个按钮不再是即时满足的来源,而是遗憾的来源。 我所有的工作,我所有的编辑都丢失了。 我要么必须花费比原来更多的时间才能将所有编辑转移到文档的新版本中,要么
- 我必须将之前翻译和编辑的文档修改到新设计中,然后实施必要的额外编辑。 两种选择都很糟糕。
我打自己的头。为什么我不直接使用我们的翻译平台呢? 是匆忙吗?是最简单的过程的诱惑吗?还是我低估了我们的技术的作用以及它确实增加了多少价值?我没有预料到我会不得不更新文档我猜大多数翻译文档的人认为他们翻译文档的目的是有限的,而不是将其视为动态文档。 在大多数情况下,这可能没问题,但当您确实有一个会随时间变化的动态文档时,必须在我们的环境中使用知识管理功能。如果我通过 Bureau Works 处理文档,我会在第一次运行中存储所有编辑和所有术语首选项。 当第二个版本出现时,我所要做的就是根据我创建的知识库重新处理文件,只关注确实已更改的句子。 而且,除了一些我必须在这里或那里解决的格式标签外,该设计在很大程度上也将无缝地继承下来。但我没有那样做,我也没有想出如何让时间倒流。 我选择经历这个过程,要求我的设计团队重新设计我最初翻译的文件,然后手动实施必要的额外编辑。 遗憾的是,我们在这个过程中损失了至少 20 个工时,而这些工作本可以在几分钟内解决。
这是遗憾 #1: 忘记版本控制和更新 - 它们会咬人
我以为我已经解决了我的问题,但事实远非如此。 仔细查看我的原始翻译后发现,我进行了许多不一致的改进,使文档看起来比最初预期的要薄弱且不那么专业。 虽然我们的软件确保重复的部分被标记,并通过词汇表增强一致性,但GoogleTranslate将整个文档视为一个平面文档,并不提供这些提升生产力的工具。

这让我感到遗憾 #2: 尝试在没有专业工具的情况下进行专业工作并不是一个好的最佳实践,并且不可避免地导致可疑的结果
最后但同样重要的是,我在寻找这些不一致时一度变得疯狂。 大量的搜索和替换。 在文档上上下滚动很多次,感觉就像打地鼠一样。 对于我修复的每一件事,似乎都有新的问题出现。 到那时,我已经至少又损失了两个小时自己的时间,变得沮丧,离我想要的最终结果还很远。 很明显,如果我从一开始就使用正确的框架和工具,我会受益更多,这就是我所做的。 我以构建翻译工具为生。 我从骨子里相信他们,我仍然相信这一次我可以用一种更简单、更随意的方法逃脱,而不会产生太多后果。 我差不多侥幸逃脱了,直到版本更改伏击了我。
这带来了遗憾 #3: 除非真的不可能这样做,否则以最好的方式去做
我们经常想以最直接、最省时和最经济高效的方式解决问题。 但是,当涉及到语言时,不仅仅是词语很重要。 他们会。 但比文字更重要,框架更为重要。 当你有正确的框架时,你可以相对无缝地处理意外的版本更改、最后一分钟的编辑、多语言文档制作的高峰,同时确保你的品牌声音保持一致和完整。 我知道这个。 但我一瞬间“忘记”了这一点,并做出了一个有问题的决定,当你把所有相关方的时间加起来时,这让我们损失了数千美元。
结论
GoogleTranslate 让我感到敬畏和钦佩。 他们迄今为止在机器翻译方面所达到的准确性水平、与其工具的集成以及使用的便捷性都令人惊叹。 但我学到它就像我学到生活中的大多数东西一样:通过艰难的方式。 如果你从一开始就没有正确的框架,即使你认为不需要,或者特别是当你认为不需要的时候,那正是你不能没有的时候。