您在开发时会考虑本地化吗？

在开发软件项目或网站时，您是否考虑到本地化？

我的意思是

• 外部化所有字符串，包括错误消息。
• 不使用包含文本的图像。
• 设计UI时要考虑文本扩展。
• 使用伪翻译来测试用户界面的早期阶段。
• 等等

在您从事的项目中，这些项目是否属于“不错”类别，并让本地化团队担心其余的工作，还是在开发过程中内置了本地化准备？我很想听听开发人员如何看待本地化。

我在一家财富500强公司工作，我们始终从本地化入手。我们的项目通常仅针对美国，但是多年来，我们会为客户编写一个应用程序，然后其他人会看到它并说：“嘿，那将非常适合X国。” 接下来，您知道的是您正在遍历添加本地化的代码。从一开始就真的不需要花费更多的时间来构建应用程序，因此我们只需这样做。再加上额外的好处是，当客户确实来找我们并要求使用（选择您的语言）他们的应用程序时，我们将文件交给他们，告诉他们将其翻译为（选择您的语言），我们就完成了。

我认为这在10年前很重要。最近的技术解决了这个问题。

我生活在一个有3种民族语言的国家，而其中只有一种是少数民族。

要了解由此可能发生的问题，就好像美国的西部地区说的语言与东部地区（非常）不同。认为在该国中部，人口有所融合，因此您必须在各处使用两种语言。

在桌面应用程序和网站上拥有4种语言非常普遍（3种国家语言+英语）。有时这是一种义务。

我了解本地化的原因是我受到环境的限制。是的，几年前，我对此感到担心。

现在，我不太在乎本地化，因为最新的IDE工具使您可以轻松地将任何静态应用程序转换为完全本地化的应用程序。

我在Visual Studio .NET中使用的工具：

• CodeRush，一个Visual Studio插件，可让您将硬编码文本移动到资源文件中。
• Easy Localizer，将标签提取到Excel文件中，在其中添加所有其他语言，然后再合并回资源文件中。

我的大多数客户只需要一种语言，并且实际上指定了一种语言。因此，我们不会花时间对应用程序进行本地化。但是，这并不意味着我们可以完全忽略其他语言。因此，我们坚持以下基本原则：

• 随处使用Unicode。这是2k10，没有理由不这样做。
• 设计时要使布局具有一定的弹性。即使使用全部英语，在相同的磅值下，不同的字体也具有非常不同的屏幕显示。
• 将应用程序功能/数据建模置于视图层之外

就个人而言，当一种潜在的本地化语言与该语言根本不同时，在设计应用程序时所进行的工作比简单选择文本要多得多。尽管文本替换有助于并且将使公司能够较早地在新位置进行“快速而肮脏的”实施，但它并不能解决另一种语言的用户在思维方式上的根本差异。

我已经学习过日语，虽然我只能认为自己是该语言的入门级新手，但我知道有些概念没有直接翻译的含义。关于什么使有用的东西有不同的想法。虽然主要的主要概念可能相似，但细节确实对用户有所不同。

为了真正满足不同文化的需求，您的应用程序需要崭新的面貌。这就是为什么模型/视图/控制器分离变得更加重要的原因。只要应用程序以相同的方式运行，就可以完全替换视图部分。发生这种情况时，有人计划支付一些真金白银以正确解决问题。

我们已根据需要完成了此工作：由于我们扩大了市场，现在面向客户的工作都已经考虑到了i18n的需要，并且一些内部的工作现在也支持i18n了，因此使用该工具的员工不必说英语。

因此，我们是作为一家初创公司按需进行的。

听起来人们在轻轻松松地进行了100亿次努力。尤其是在使用英语作为原始语言的情况下，很容易忽略这样一个事实，即其他语言通常甚至需要30％到40％的文本空间。这要求翻译人员使用不太容易理解的缩写，这当然不利于用户体验。

通常，我会在以后需要时添加国际化，即使我从一开始就知道会需要它。使用我使用的语言，在一个单独的阶段进行操作并不是很困难，而且我可以将繁琐的方面排除在早期的建设性阶段之外。

我编写了android应用程序，使用Java样式字符串文件进行本地化非常简单。在所有Android语言上实现完全国际化的工作几乎为零。

答：可以。尽管在我工作的环境中（Python / Zope / Plone），在以后对字符串进行本地化非常容易，所以如果从一开始就不需要，我就跳过它。

但是我将文本存储在unicode对象等中。

所以，是的。我确保我的应用程序相当容易本地化，即使未本地化也可以在国际环境下使用。不这样做是错误的，因为所需的工作量很小，而收益却很大。