刚开始时一些应用程序开发人员很可能没把本地化放在心上。然而，提前做好准备，并在余下的工作中设计好合适的工作流程可以从一开始就节省大量的时间。
如果您开发了款很棒应用程序或游戏，您会想让所有人都试着使用它，使用的人越多越好。本地化就能提供相应的帮助。对大多数的移动应用程序开发者来说，语言的本地化和适应文化间细微差异只需要一段时间而已，而这段时间也绝不会被浪费。
把应用程序本地化成 10 种，20 种甚至 50 种语言是一项非常有价值的工作。首先，从应用商店的页面开始到 Premium 会员升级，本地化后的应用程序有助于改善用户体验，从而提高用户忠诚度，日活用户数量和客户终身价值最终使开发者的利润最大化。
现在，您已经了解了这项工作是值得的，接下来我们将深入了解如何建立一个最佳的本地化项目。
首先我们要明白，世上没有能马上做好本地化的灵丹妙药，但合理的日程安排会让你走在正确的方向上。
为了确保您的应用程序值得花时间做本地化，要考虑 2 个重要的方面。
受众：您的目标受众是谁？ 他们讲不同的语言吗？ 如果是，应该以哪种语言作为本地化的起点？ 当地市场的潜在用户如何细分？ 他们的具体需求和偏好是什么？ 他们真的需要您的产品吗？他们如何从中受益？ 您的目标受众与当前用户有何不同？ 需要考虑哪些文化差异和当地准则？ 应该本地化界面还是订阅方案？ 此外，这个市场的付费功能是否应该与您当前的市场相同？ 应该本地化哪些类型的内容，按什么顺序本地化？
竞争对手：当地市场是否有细分市场？ 是否有竞争对手？他们是否试图将产品本地化？ 可以从他们的经历中吸取哪些教训？
如果未来要对本地化项目的工作流程做调整，市场调查可以提供有效的帮助。首先，您会得到一份标有对应使用语言的国家名单，确保您了解某个国家和其使用的语言，例如，加拿大人根据生活地区的不同，有的说法语，有的说英语。因此，您的本地化计划要包含跟法式法语和英式英语有些许区别的加拿大式法语和加拿大式英语。有些时候，知晓最流行的本地化语言也很重要。
虽然许多人将这两个术语用作同义词，但它们实际上意味着两件不同（尽管相关联）的事情。 国际化和本地化都旨在使应用程序适合特定的地区。 不过，国际化更加注重应用开发的技术方面，而本地化更加注重了解某种文化的细节，并根据它调整应用的内容。
移动应用的本地化是使其看起来适合特定目标受众的过程。 例如，本地化包括将文本翻译成所需的语言，转换所有必要的指标，包含特定文化的视觉元素，以及考虑当地法规。
反过来，国际化侧重于为本地化准备应用的技术方面，并涵盖与应用结构和架构相关的流程：多语言选项、不同的文本格式，以及从源代码中提取文本。
规则是确保应用在本地化之前具有适当的国际化版本。
本地化工具包是为高效率本地化工作所需的全部文件和文档的集合。最重要的是，这些从源文件（代码）传输过来的资源文件需要翻译。
另一个必备元素是术语表，它应该包含应用程序或游戏中最重要和最高频的词汇、短语和术语（角色名称、状态、游戏内物品、位置等）。术语表有助于保持整个翻译的一致性并加速本地化的过程。翻译人员无需直接询问应用程序开发人员即可使用它。术语表可能是一个单独的文档或翻译平台界面的一个部分（如果公司已经选择了某平台）。以下是Crowdin 本地化平台上的术语表。
作为一家专业的翻译和本地化公司，Alconost 的经验表明，为本地化团队提供风格指南简介也是一种很好的做法。 风格指南是一组帮助译员维护品牌讯息并确保译文准确无误的说明。 它定义了译文的语气、品牌风格、特定俚语的使用、正确的形式、缩略词等。
此外，lockit（“本地化工具包”的缩写）也许包含翻译记忆库（之前翻译过的实例）和上下文背景信息文件：游戏实机视频、音轨，甚至（在极少数情况下）产品构建。
本地化团队通常包括：
负责监督项目工作和截止日期的项目经理
负责组织和管理工作流程的本地化工程师
负责本地化产品的质量的 QA 经理
本地化过程也会涉及到组建一个能翻译多达 50 种语言，（甚至特定方言）的翻译团队。
尽管部分开发者采用机器翻译或者众包翻译，但与专业翻译相比，前两者无法保证一致的翻译质量。
某些公司有自己的本地化团队，另一些公司则更愿意将整个本地化流程外包。即使你不能组建完整的本地化团队，但在公司中保留至少一到两个本地化负责人是很值得的。
到这一步，就跟选择本地化平台密切相关了。如果本地化工作在云端进行，不仅可以同时让尽可能多的团队成员跟踪了解本地化项目的最新情况，还能让经理、开发人员、翻译人员和编辑人员之间的沟通顺畅进行。
在 Excel 工作表中进行本地化则没什么优势，即使把工作表下载到本地化平台上，大型团队也无法实时协作。
inDriver 应用的本地化案例研究
inDriver 是一款在 31 个国家/地区运营并支持 11 种语言的交通app。 它最初是一个小型的本地拼车应用。 inDriver 团队在本地化流程中面临的最大挑战是：
团队分散式管理以及流程缺失：翻译人员只负责他们那部分的工作，不知道其他团队成员在做什么。
数量和质量的问题：部分翻译来自社群，他们不愿意为少量文本内容提供高质量翻译。
罕见的语言和方言：社群无法为此提供翻译支持。
最后，inDriver 将整个项目转移至一个基于云的翻译平台，这帮助他们建立了适当的管理流程并使整个团队的工作同步。inDriver 还订购了专业的方言翻译，同时对社群完成的翻译进行再次校对和测试。
本地化您的应用
回到国际化的话题，在准备阶段我们提到过，开发者应该能够从源代码中提取本地化所需的资源文件。 通常，可本地化字符串是 .xml、iOS .strings、.resx、.po、.json 或其他可转换格式。 如果没有正确国际化，可能需要对应用进行特殊的集成来提取和待翻译文本。
在我们进入本地化流程之前，先了解一下应用程序本地化的关键组成部分。
应用商店页面本地化背后的理念是让应用程序对当地用户更具吸引力。它包含以下几点：
关键字的选择很重要。不同国家/地区有搜索频率各异的关键词，简单地翻译这些关键字是不够的。关键字本地化意味着使用专门的 ASO 工具研究相近的术语并根据地区选择最流行的术语。
应用程序介绍的本地化不仅是要做翻译，还要通过使用特定文化的关键词、短语、术语为相关用户群调整内容表述。苹果商店和谷歌商店都允许对应用程序提供多种本地化介绍。这意味着 App 可能有一个默认介绍（比如英文）和其他根据用户位置进行过对应本地化后的介绍。根据用户偏好和应用程序版本，在不同的本地化介绍中突出显示不同的应用程序功能也是可以的。
涉及到应用下载时，屏幕截图的本地化是最后一步（但绝不是最不重要的）。
如果您的应用程序或游戏在商店页面上有视频预览，那么最好也考虑本地化剪辑。除了视频本身的本地化外，还要考虑配音和字幕的本地化，如果您的预算紧张，可以另做打算。
Full HP Ltd. 的案例
该应用的屏幕截图和说明都被翻译成土耳其语，这让用户访问量增长了 18%。 统计数据还表明，用户大多被屏幕截图和其中包含的文本所吸引 — 只有少数用户真正阅读应用介绍。 当屏幕截图为当地受众进行了适配后，应用的下载量显著提升，进而也提高了收益。
只翻译截图中的文字是不够的部分国家会可能需要使用不同的主色调，添加或更改视觉元素等。
文本本地化不仅仅是翻译，它应该让文本看起来更像“当地的东西”。 这意味着使用特定用户群体常用的特定短语、单词和行话。
本地化完成后，开发人员会建立应用程序的本地化版本并就故障和翻译流程做测试。让另外一个人来做测试、编辑是不错的主意。
通过社交媒体、论坛或信使服务接触用户社群并征求他们的反馈（或者请他们成为应用程序的 Beta 测试人员）也很重要。尽管社群无法快速翻译大量文本，但可以就翻译、用户体验或用户界面的任何问题提供有价值的反馈。
用户体验/用户界面本地化有许多方面需要考虑。 不同的用户群体对产品设计、主色调和视觉元素有不同的偏好。 此外，应用或游戏的图片中的文本也需要本地化。 如果是硬编码的图像，则需要从头开始重新设计。
有时，界面元素也需要调整以适应当地语言（在长度或语序方面）。 不过，最好的做法是为用户界面元素中（尤其是菜单项和按钮中）的文本留出至少比所需空间多 30% 的空间。
用户体验/用户界面本地化通常涉及图形设计师、用户体验/用户界面设计师和开发者。
敏捷：它与本地化流程的关系
敏捷模式（一种应对快速变化的需求的一种软件开发能力，强调程序员团队与业务专家之间的紧密协作、面对面的沟通）根植于产品开发，且非常适合所有的产品开发周期。与瀑布式开发（一种最常用的开发模型，限制了开发期间团队间的交互，评估起来相当方便，由于开发计划稳定而且几乎不会发生经常性的变化从而有效地简化了项目开发的管理工作。）相反，非线性的敏捷模式允许同时执行多个任务，且互相之间不会干扰。
在 Alconost，所有可以实现敏捷的事情都应该是敏捷的，包括本地化。
一个重要的要求是敏捷本地化发生在云平台上，所有团队成员，无论是内部还是外部，都可以在云平台中进行协作。
因此，敏捷本地化流程可能是这样的：
图中显示了 Alconost 的典型应用本地化流程的概览。 敏捷本地化有很多优势，因为它有助于加快上市时间，更容易及时发现和修复错误，这意味着更少的人工和更少的额外工作，更快的本地化测试，并最终降低项目成本。
敏捷有利于开发，而且与自动化协同工作，这是高效本地化流程的另一个关键要素。
最后，由于敏捷本地化允许迭代，它不但非常符合产品开发周期的理念，又让为不同地区同时发布新功能的工作变得简单又易于操作。
持续本地化，作为敏捷流程的示例
敏捷模式可以不断的更新应用程序，从而引发其他基本的迭代过程：持续交付、持续集成、持续部署和持续本地化。可以这么说，持续本地化在理想情况下应该是持续交付过程的一个组成部分。
自动化的存在，使持续本地化成为可能。如图所示，资源文件、翻译记忆库和术语表都上传到了 TMS（翻译管理系统或平台），理想情况下它应该是个能让翻译人员和其他团队成员进行协作的基于云的系统/平台。
理念就是，即使是一小部分可本地化的内容，一旦准备就绪，也可以重新集成到源代码中，并参与进从构建到部署至后续应用程序发布的整个过程。
TikTok 以超过 75 种语言在全球 150 多个国家/地区运营着，因该公司需要将其本地化为一些稀有语言（如南非荷兰语和他加禄语(译者注：主要于菲律宾吕宋岛使用)）并每周更新一次，敏捷模式和持续本地化是近乎唯一的选项。
这些情况极其严苛，有时甚至只有 24 小时作为周转时间。Crowdin 是该公司选择的平台，其基于云的本地化工作流程使他们既能在截止日期前完成工作，并遵循以前的翻译记忆库。
本地化流程中的瓶颈
虽然这个流程乍一看似乎很完美，但可能会遇到一些瓶颈。 我们来看看有哪些瓶颈，俗话说有备无患。
如下图所示，当需要从源代码中获取包含待翻译文本的资源文件，然后将其下载到翻译平台时，这一流程中最常见的瓶颈之一就会出现。 这里可能会出现两个问题：
无法从源代码中提取文本。因此，资源文件没有包含整个文本。
这些问题的出现通常是因为缺乏国际化，即本文开头所描述的技术准备工作。 我们来看看为什么在创建资源文件时文本会部分或全部丢失。
硬编码文本
代码中的文本无法用翻译工具提取，并且会丢失翻译目的。例如，如果您在图片或其他设计元素中硬编码某些文本，这些元素将不会被本地化。如果只有部分文本是硬编码的，那么文本可能不会被完全翻译，或者其中的部分内容会丢失。
字符串拆分
如果句子或短语被分成几个部分，或者在没有任何上下文的情况下包含占位符，它们就很容易被提取为单独的内容部分进行翻译，或完全失去语境。
例如，当数字与单位分开时，或者占位符中的某些术语在句子外时，就会发生这种情况。为占位符提供上下文背景信息描述是一种很好的办法。
编码问题
编码问题可能在搭建本地化版本后出现。如果您得到了一些��� spécîål”一样的乱码，可能是由编码问题造成的。
为避免编码错误，最好使用 Unicode（UTF-8，最常见）而非其它编码方式。
同样的道理也适用于字体。如果某些花哨的字体不包含适用于所有语言的字形，则可能需要为不同语言选择不同字体。
如果翻译流程没有得到适当的优化，组建一支翻译成数十种语言的译员团队似乎是一场噩梦。首先，对于复杂的项目，最好将所有内容都放在在线翻译管理平台上。云平台可以让每个人实时查看更新，无延迟地查看评论，并将本地化工作与术语表或以前翻译的文本（翻译记忆库）同步。
其次，指定一名项目经理来监控项目进度和截止日期，并充当其他团队成员间的沟通媒介。
上下文由术语表、翻译记忆库、占位符注释、平台上的翻译批注注释和及时沟通提供。 所有这些组成部分对于准确快速的翻译都至关重要。
例如，缺乏沟通可能会导致指标和独立用户界面元素的翻译错误，或对可能具有多种含义的术语的解释错误等问题。
这条规则很简单。 首先，译员应该玩游戏或使用应用。
对于游戏本地化，最佳人选是那些本质上是游戏玩家，职业上是译员的人。
其次，在任何可能的情况下，译员都应该有使用移动应用的经验。 否则，开发者可能会收到不真实的文本，其中充满了不正确或不寻常的术语。 即使是意义上的细微差别也会影响用户体验。
如果说上下文是皇后，那么用户就是国王。
搭建本地化版本后，收集用户对 Beta 版本的反馈绝对不会错。一个重要的前提是，你必须拥有合适的渠道和恰当的流程来收集反馈。
例如，您的团队成员可能会在社交媒体上参与用户讨论或剔除机器人评论。这种性质的压力测试是本地化过程中的最后一步（但绝不是最不重要的一步）。
为了成功地本地化您的应用，您需要了解您的受众和竞争对手，实施国际化，组建团队，努力在所有流程中应用敏捷方法，并选择本地化团队来帮助您完成这一过程。 保持敏捷，付之行动。