本地化游戏专案经验 这一篇文章补充描述一下我曾做过的案子关於多国语系的做法 网志完整版 https://ndark.wordpress.com/2024/11/15/%e6%9c%ac%e5%9c%b0%e5%8c%96%e9%81%8a%e6%88%b2%e5%b0%88%e6%a1%88%e7%b6%93%e9%a9%97/ 缩网址 https://tinyurl.com/mr2zex9c 完全不做本地化 是的，如果是接案公司，或者是只打单一语言市场，是很有可能完全不做多国语系的。 在这样的前提之下，工程人员如果判断“没有”这项规格，可以加速多少时程。确实因为 这个原因完全不做多国语言的系统。 最阳春的做法是把语系文字写在程式码里面。 读者一定会浮出这样的疑问：谁会这样做游戏！ 在谈下去之前，我先谈一下我在2012 Kobayashi Maru Commander(小林丸指挥官)的案子 的做法 标签参数的格式 在小林丸这个案子，是使用语系分离，分行式标签参数格式文字档的做法。 如果读者去看Unity的meta档案可以发觉就是用类似标签参数格式来存资料。通常是以每 行一条<标签>:<数值>的格式来存取。 在笔者2018年服务於Ubisoft的Growtopia案子中，伺服器传给客户端的通讯资料也是这样 存的。 在小林丸案的每个语系里面存相同的标签，例如： 中文语系内是 System_Config:系统设定 英文语系内则是 System_Config:Config. 如果我没有记错，Android的语系设定也是以语系分离。 语系分离的好处是存取档案後在切换语系前都不用再读取。 而语系结合的缺点当然就是相反过来，读取语系文字档的时候，就会同时取得其他语系的 内容。其他语系的内容即便没有使用，仍会占用到记忆体。 回到把语系文字写在程式码里面。 就连草根开发者NDark都懂得要把多国语系存成一个参数档。 但如果我告诉各位，我职业生涯中看过不只一次完全不做多国语系的案子。 我在Ubisoft服务维护的Growtopia案因为一开始是独立开发，所以起步时就决定只做英文 版，所有的文字都写在程式码内，直接以明码方式传给客户端。产品红了之後继续维护每 个月持续版更，内容当然越来越多，要重新针对所有游戏内容进行翻译的成本就越高，所 以後面不管多国语系的呼声需求多强烈，都会在讨论中被驳回。 我在2015年我参与过本地化的日本游戏<Hortensia Saga(苍之骑士团)>的前几个版本日本 原厂团队也是一样把日文写在程式码中。原厂团队是要委托代理商发行台港澳中文版後发 现了这个是一个问题，才调整优先度做出决定在後续的版本将多国语系抽出为Excel的决 定。 在这个过渡迭代的过程中，交付给台湾的第一版还不具有Excel，所以日本代理商SEGA还 派出工程师做出了文字分析工具（Parser）。将程式码内的文字挖出来，做成类似csv的 档案，然後翻译後再使用另一个脚本工具去将中文取代入程式码内。这样就是当时前几版 的中文版的做法。 不过值得一提的是日本开发团队通常都具有强大的Excel功力。可以看到他们习惯透过 Excel表单内的脚本进行包版运作。这点我在台湾团队比较少看到。 当然因为日文Excel软体制作的脚本在中文电脑跑有没有什麽不相容的问题，这就是另一 个故事了。 因此得证，只要规格没有要求多国语系，或是只做单一市场，或是为了赶时程。不做多国 语系也大有人在。 开始使用Google Spreadsheet 在2017年的时候我制作了<Really Really(真的)>这款游戏，这款游戏我就开始使用 Google spreadsheet。透过NGUI内建的功能，将试算表转为以逗点为区隔的csv使用。 <真的>案是以文字对话/长辈梗/迷因梗为主的游戏，我当时还委托专业翻译人员做英语版 翻译。 比较有值得一提的是有些文字不适合直译所以关於地区梗的部分我会直接向翻译人员下指 导棋（例如说太阳花/德国眼镜翻译成Young Protestor/X-Ray Glasses）。 也正是在Caravaneer 2的翻译经验，在<真的>一案，其实是有两个繁体中文版本，一个是 繁体中文，一个是网民中文版本。 <真的> 一案中还有针对不同的语系的图档，语音档案也做出多国语系。这边是使用 Assets Bundle 的 variant 标签，以相同档名不同variant来实作（在Addressable系统 是叫做label），判断语系来显示该语言的图字，特效，及语音档。 顺带一提，2022年的<Supernature Event Control Inc.(打怪特勤队)>案我尝试做台语的 多国语系，当时是切成台语汉字，台语教荐字，台文三种语系，很可惜我没办法资助台语 工作者来完成整个语系的翻译。目前台语语系是透过伺服器设定档将其隐藏起来。 使用Google translation的指令做机翻 在2020年的<Village Master(村庄盖出去，野兽进不来)>的案子中开始将多国语系的经验 扩展，当然<真的>一案中发觉委托翻译社的费用以自资案来说是一笔无法负担的支出，最 後决定先使用机翻，看哪个市场比较有希望再进行推广，最後透过机器翻译的帮助下，除 中文英文外，总共翻译了马来，德文，西文，法文，葡文，俄文，日文，韩文，波兰文， 总语言数达到十一个语系。 除了游戏内的内容，在平台商店的更新版本内容，行销文字，在社交媒体的行销文字，也 都是透过这样的表格来做翻译。 表格的命令其实一点也不难。只需在试算表中加入命令： =GOOGLETRANSLATE(E860, "en","de") 指定要翻译的内容，原文字码，翻译目标语言字码即可。 不过小心，如果机翻数量庞大脚本也需要一定时间完成所有试算表栏位的翻译。如果翻译 完成，建议将翻译的结果重新以文字方式复制一份贴上原处，取代命令算式，固定下来。 避免每次表单变更的时候都触发机器翻译。（另外提醒，就我的经验，这个语法有机会会 因为某些暂存的原因而出错误讯息卡住。） 至於机械翻译有没有效果呢？我个人的经验是，比什麽都没有好。尤其是在几个国际化不 高的语言国家，被好像看得懂的文字骗去下载，然後留言说："游戏有趣，就是翻译是个 屎！"还是比完全被忽视好得多。（包含几间公司的经验是韩国与日本很在意标题与商城 画面的截图要有当地文字，俄罗斯等前苏联邦国家，与阿拉伯国家因为地缘政治的关系算 是游戏市场的孤儿，所以有当地的语言会很容易进入玩家的视野。） 介面尺寸在不同语言的适应性 部署多国语系，有一个很大的问题，这个问题至今我还没办法解决。 那就是每个语言针对翻译结果的长度不好控制。 如果介面是以英文或中文还好调整，毕竟文字内容开发者自己可以代换。但是碰到其他语 言，尤其是字母符号不同体系的语言就很难处理。想改也不知道怎麽动手。 比如说德文就是出名的长单字。（笔者自己有德文基础，所以我还能知道要拆字该怎麽着 手。） 阿拉伯文自右书写的系统（句子内阿拉伯数字又是左起）会很令开发者意外。 如果调整文字尺寸让其自动缩小适合介面，那麽长单字会注定被缩到看不清楚。 而且介面上忽大忽小的文字简直就是对美术人员的一种逆鳞。 这点我希望读者能分享一些意见。 跟翻译外包相关的议题 使用google spreadsheet的时候如果有多人协作或是外包作业的需求建议将所有翻译条目 的索引或顺序固定，不要因为好看或是分群忍不住调整顺序。尽量能遵从後到递增的守则 来持续开发。 其原因是从开始委托外包到收回是需要时间的，为了不要让人为作业疏失干扰到原始的档 案，最好的情况是开始委托外包时，就复制一份表单给翻译者。 所以回收时如果翻译条目的顺序改动了，那就无法整个表单复制整合起来。必须人工确认 贴上。而需要翻译时多半团队内都缺少懂该语言的成员（否则为了节省成本都有可能自己 翻）。所以不能大范围贴上，很容易造成人为作业疏失。 顺带一提，2018年Growtopia的案子中，另一个之所以无法下决定开始翻译的原因是：开 发周期过短。当时游戏是以一个月为一周期在开发新功能，每个月产出三十到五十个包含 装饰或系统甚至故事的功能，时程已经挤到不行，企划都是在送审打包最後一刻才能把英 文顺好。因此若要再挤入三天五天甚至一周的翻译工期，就得更早交付翻译者原文。这对 於Growtopia这种几乎大多数营收都来自每个月更新释出的新道具新功能，显得不实际（ 翻译如果到了第二个月才更新，那麽对营收贡献也不够有成效了）。（Ubisoft 是一个庞 大的帝国，帝国内不乏有各种服务支援部门，Growtopia曾经靠着帝国支援移植手机平台 到家机，完成不可能的任务。连我们团队也判断很难在帝国内找到能这样一个月只紧急高 强度配合一到三天的翻译工作者。） 还是建议及早部署多国语系的系统 从工程的角度来看，不管最初版本是否只有一个语系，文字有多少，都建议及早部署多国 语系的系统。这样才不会陷入Growtopia的成本沈没效应（内容越多，就越难做出开始翻 译的决策），所以LocalCoop想要重现的滚动式翻译才这样有意义。 当然我连续几个专案都沿用同一个系统，所以重复部署这个功能对我来说就只是复制一份 云端表单而已。 更不用说因为变成了一个资源档案，那麽实现下载更新，就容易许多了。 使用滚动式的翻译平台的好处 在2014年Caravaneer2的案子中，也就是目前 LocalCoop 尝试重现的方案，是采用滚动式 的方式来与社群合作。滚动式的好处体现在几个地方： 第一个是开发是持续的。与代理案能够一次性不同的是，自研案的内容都是逐步产出 的，而每次的版更都有可能造成旧文字的变动，此时翻译协作也必须知道旧的修改到底在 哪里，才能迭代翻译步骤，而不是全部重新翻译。程式人员对於版本控制已经相当熟稔， 但翻译工作的版更管理比较少人关心。 第二个是由於游戏内容的产出是滚动式的，早期的翻译者不会知道某些伏笔会在後续 的篇章中出现，所以有必要在翻译的过程中逐步建立一套关键字的索引机制（通常是阵列 中索引比较小的那些条目）让旧的翻译者能够回顾，新的翻译者也在进场後先查阅这些条 目。这就像是给翻译人员用的教学。 第三是翻译的进度也是滚动式的，翻译者随时都可以进场，以追上原文的进度为目标 。在重大版本的释出时，做一个验证，只有达到一定程度翻译完成的进度的语系。才会被 打包进入版本交付给玩家。 -- "May the Balance be with U"(愿平衡与你同在) 游戏设计教学，讨论，分享。欢迎来信。 黑水沟历史文库 https://ndark.wordpress.com/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.193.160.149 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/GameDesign/M.1732275957.A.0AD.html ※ 编辑: NDark (123.193.160.149 台湾), 11/22/2024 19:46:19 ※ 编辑: NDark (123.193.160.149 台湾), 11/22/2024 20:40:41 ※ 编辑: NDark (123.193.160.149 台湾), 11/22/2024 20:40:53 ※ 编辑: NDark (123.193.160.149 台湾), 11/22/2024 20:41:06