在本地A拷贝远端的服务器B上的文件：

scp root@[B的ip地址或主机名]：[B上存放文件路径] /文件 [A上存放的文件路径]

如：

scp  root@192.168.3.58：/home/oracle/test.sql  /home/oracle

在本地A拷贝远端的服务器B上的文件夹及文件夹下的文件：

scp -r root@[B的ip地址或主机名]：[B上存放文件路径]   [A上存放的文件路径]

如：

scp -r root@192.168.3.58:/test  /test

1.修改/etc/profile文件

前面我们已经多次提到了伪本地化build,今天我们就来谈谈它。
软件伪本地化build从字面意思来理解就是一个假的本地化build。伪本地化的英文是“Pseudo Localization”，它不是软件真正本地化，而是在源语言软件的基础上，按照一定的规则，将需要本地化的文本使用本地化文字进行替换，模拟本地化软件的过程。经过这种处理得到的软件的界面将包含本地化文字，看起来像本地化软件，所以称为“伪本地化”。

在进行国际化测试时，我们需要保证被测软件有足够好的可本地化能力，也就是我前面说过的国际化测试第三级测试，用英文build是发现不了国际化测试第三级的问题的，但是国际化第三极的问题又不能等到本地化build出来再进行测试然后进行修改，等到那个时候已经太晚了，所以在国际化测试过程中就出现了伪本地化build.

伪本地化build主要是对资源文件进行处理，给资源文件中的每一个字符串加前缀和后缀，有的时候会使用自动翻译将资源文件直接范围，然后做一个伪本地化build.

使用伪本地化build可以确定是否存在硬编码的字符串，如果所有的字符串都是增加了前缀或后缀，或用本地化字符替换了，那么运行软件时出现的英文字符串则属于不能本地化的硬编码缺陷，即这些英文字符没有包含在可以本地化的资源文件中。

使用伪本地化build还可以发现字符扩展的问题，大家都知道，一个语言翻译到另外一个语言时，字符的长度会发生变化，如果界面上没有预留足够的空间，则会出现翻译后字符串的裁断。在使用伪本地化build时，因为字符串在英文字符串基础上增加了前缀和后缀，长度会变长一些，如果界面上控件的长度没有考虑国际化，则很可能出现截断问题。比如button,label,dropdown list等名字或值显示不完整，影响用户阅读和使用。

使用伪本地化build进行测试，因为在字符串在英文基础上增加了前缀和后缀，还可以发现缓冲区溢出问题，如果你在使用伪本地化build上测试发现功能问题很可能是缓冲区溢出问题。

使用伪本地化build进行测试,还可以发现字符串串联的问题，就是一个长字符串是根据程序运行过程中变量的值由两个或多个字符串拼接而成，这样会影响本地化的翻译工作。我们可以根据字符串的前缀和后缀来分析字符串，判断这类问题。

使用伪本地化build还可以发现一些对话框大小的硬编码问题，如果对话框大小不能根据对话框上的显示文字多少进行变化，则会影响本地化翻译后的显示。

关于伪本地化build上面由于字符长度扩展引发的截断问题我们还要分不同的情况，这些问题有可能不需要修改代码，而是直接调整资源文件就可以改好，这样，这些问题就可以直接交给本地化的工程师去做，国际化的开发就可以不去关注了，如果出现的截断问题必须通过修改代码才能修复，则必须由国际化开发人员修复。但是这种问题测试人员不好判断，可以寻求开发人员的帮助，在做伪本地化测试前，请开发人员分析程序UI显示是否可以通过资源文件调整，如果可以通过资源文件调整来改变UI显示，则测试人员在测试过程中可以不关注截断类问题，省去很多报bug的时间。

在使用伪本地化build测试过程中也可能会发现有些问题是伪本地化build的问题，和产品本身无关，这个主要看做build的人的质量，比如字符加前后缀，很可能有些比较特殊的地方没有加上，或有问题，这些具体问题在做项目过程中要具体分析。

看到有人在问全球化和国际化的关系，国际化和本地话的关系，我们今天就简单说说这三者之间的关系。

我们所说的全球化，国际化，本地化都是针对软件来说的。简单的来说全球化=国际化+本地化。

所谓的全球化，就是软件的目标市场并不是一个国家，而是多个国家或区域，我这里借用一下崔启亮老师的书里面的定义

全球化软件是为全球用户设计，面向全球市场发布的具有一致的界面，风格和功能的软件，他的核心特征和代码设计并不仅仅局限于某一种语言和区域用户，可以支持不同目标市场的语言和数据的输入，输出，显示和存储。全球化软件也称为国际化软件，全球化对应的英文是Globalization,缩写为G11N.G是首字母，N是尾字母。11表示在首字母G和尾字母N之间省略了11个字母。

其实全球化软件按照字面意思理解的话也可以叫国际化软件。全球就是针对多个国家的意思，国际化也是针对多个国家的意思，但是全球化软件在开发过程中又可以分为两个大的部分，一般叫做国际化和本地化，为了将此国际化和彼国际化分开，所以叫做全球化。  所以全球化=国际化+本地化

这块主要是定义的问题，如果把一个面向全球用户的软件叫做国际化软件也可以，但是如果在做这个软件的公司内部就不好区分这个大的国际化和他下面细分出来的国际化，所以一般就叫做全球化。所以如果你是给公司外部的人来说，不关注技术细节的话，说你的产品是全球化软件或国际化软件都可以。但是公司内部具体去做这个软件的话最好还是将全球化和国际化定义严格分开。崔启亮老师的书<<国际化软件测试>>，我感觉名字叫做全球化软件测试可能会更好一点，当初我看了名字我还以为是讲做国际化的，结果发现国际化和本地化都讲。

下面我们来说说国际化和本地化的关系，其实我和项目组里的人合作了很长时间，他们有时候也是分不清楚国际化和本地化，大家对本地化可能了解的比较多，因为这个也比较好理解，就是要做不同语言的本地化版本。但是国际化具体做什么他们就不是特别清楚，所以两个老是搞错。

我们还是来引用崔老师的定义：

软件国际化就是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化习俗，能够在创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。国际化的英文单词是Internationalization,所写为I18N,其中I是首字母，N是尾字母。18表示在首字母的I和尾字母N之间省略了18个字母

软件本地化是将一个软件产品按照特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。本地化的英文对应Localization,缩写为L10N,其中L为首字母，N是尾字母，10表示在首字母的L和尾字母的N之间省略了10个字母。

我们从上面的描述上去分析，国际化需要保证功能和代码设计能处理多种语言和文化习俗，在创建不同语言版本时，不需要重新设计源程序代码，这个说明国际化实际上是为本地化服务的，其实在软件开发过程中加入国际化的设计就是为了更好，更快的出本地化版本。国际化并不针对某一特定语言来做，国际化做好了的话，你的软件就可以处理多种语言和文化习俗，语言也就是各种国家的文字显示，输入输出，各种语言的操作系统上运行，习俗通常指的是区域相关的，比如日期时间显示格式，数字，货币符号，姓名显示顺序等。当你的软件如果国际化做的比较好时，在做本地化时就不需要重新设计或修改源代码,只需要进行资源文件的翻译，然后出本地化的build. 而本地化是针对特定语言的，特定市场的，如果该语言和该市场没有特殊要求，那么简单的说就是一个将资源文件进行翻译，然后出一个本地化的build，然后测试该本地化build上本地化问题，比如字符串没有翻译等，这个是全球化软件最理想的情况，但是往往个别国家或区域对软件在基础功能上又有些特殊的要求，本地化组需要在基于已经发布的英文版上增加特色功能然后自己发布。

我们简单的总结一下本地化测试和国际化测试，基于比较理想的全球化软件开发模式，各个国家没有自己特殊的需求

1 测试需要用的操作系统：

国际化测试人员一般会基于多个语言的操作系统进行测试，因为国际化测试需要负责软件对各个不同国家操作系统的支持。一般至少选择两个，亚洲为代表的比如日语，和欧洲为代表的，比如德语。

本地化测试人员一般只在某一个特定语言的操作系统进行测试。除非该测试人员要负责多个语言的本地化。

2 测试的build

  国际化测试一般用英文build和伪本地化build进行测试，英文build一般主要用来发现国际化第一级和第二级的问题，伪本地化build主要用来测试国际化第三级的问题。

  本地化测试一般用已经翻译过的本地化build.

3 bug的处理方式

  国际化的bug一般都是需要通过修改代码才行修改好

  本地化的bug一般都是通过修改翻译，修改资源文件来修复，不需要修改代码(这个是理想情况。)

4 测试的核心关注点不同

  国际化测试关注针对各种语言的支持，概括来说就是对DBCS，Hi-ASCII的支持，包括显示，输入，输出等，还有对于不同国家的时间日期格式，货币符号显示等

  本地化测试主要关注自己测试的语言上的输入，输出，显示，所测语言上一些特殊性等。

5测试进入项目的时间不同

  国际化测试一般很早就开始进入项目，基本上是项目开始不久，需求基本确定后。

  本地化测试一般进入项目时间较晚，一般是国际化测试进入到中期或快结束时进入。

从以上可以看出国际化和本地化的关系，概括来说就是好的国际化设计可以使软件更容易的本地化，减少本地化过程所需要的时间和精力，缩短发布时间。同理，国际化测试人员做的好了，本地化测试人员的工作就比较容易了。

在国际化测试中经常会提到hardcode的问题，也就是硬编码问题，我们今天就说一下这类问题。其实在前面我们都介绍过这块，今天主要把和hardcode有关的东西放在一起。

一般通常说的hardcode是指需要翻译的字符串没有提取到资源文件中。这些需要提取的字符串基本上包括了界面上显示的所有文字，包括lable，buttong的名字，提示信息，图片上的文字，如果log也需要本地化，那么记录log时也要将各种字符串提取到资源文件中。这一类的hardcode问题基本上属于国际化第三级的问题。这种问题其实一般不影响功能，但是会影响本地化的翻译工作，因为本地化翻译时一般是对资源文件里面的string进行翻译，如果string没有提取到资源文件中而是在代码中，那么这些在代码中的string翻译时将会漏掉，在本地化的版本上就会有没有翻译的字符串，这种问题一旦发现，就必须修改代码，将在代码中的string全部提取到资源文件中，然后需要对这些添加的string进行重新翻译，其实修改这类问题不难，一个问题可能几分钟或半个小时就改好了，主要是发现问题后会牵扯到资源文件修改重新翻译的问题，而一般翻译都是请第三方的专业翻译公司来做的，所以总的时间成本还是挺高的，所以这类问题最好在本地化介入前发现。

另一类问题，在国际化第一级中的一些功能问题其实也是由hardcode引起的，但是和第一种有着本质的区别。我在前面也提到过一些。将一些和系统有关的东西硬编码，没有使用系统变量，这种问题一旦发现将是非常严重的功能问题，一般情况下会导致某个功能不能正常使用。最常见的例子，默认安装路径C:\Program Files，这个也是我最喜欢举的例子，因为很多人喜欢用这个路径，但是微软在做本地化操作系统时，在德语等操作系统上，Program Files目录的名字也翻译了，给后来做应用程序的人就埋了个炸弹。还有一些和系统用户名组名有关功能也要重点关注，管理员在英文操作系统下为Administrators，俄语操作系统上为Администраторы，波兰语操作系统上为Administratorzy。如果直接用administrators,那在俄语，波兰语等操作系统上就有问题。避免这类问题的方法主要是在开发软件时要有国际化开发的思想，任何和系统有关的东西都不能假设其他操作系统和英文操作系统一样。

说到硬编码问题，我们就不得不提一下过度翻译(over translation)问题,如果将一些不需要翻译的东西提取到资源文件中，那么也会出问题，可能会过犹不及，比如说一个string中包含一个日期，这个日期是一个固定日期比如2010-12-31，如果将日期和其他字符一起提取到资源文件中，则这个日期可能不会根据系统的日期格式来进行变换，会引发另外的国际化问题。还有一种就是比如临时文件的路径 %TEMP%,如果把路径也提取到资源文件中，如果翻译人员将该路径进行了翻译，则log功能会由于找不到对应的路径而不能工作。过度翻译往往会引发功能问题，而不仅仅是UI问题。

关于第一种hardcode的测试比较简单，主要是在做测试工作中使用伪本地化（简单的说就是给显示的英文字符串加前后缀）build来进行测试，如果在伪本地化build上面发现了英文字符串，则很可能是一个hardcode问题。关于什么是伪本地化build和伪本地化build的作用我们在后面再谈。在测试过程中主要能确保每一个界面都跑了，所有有字符串的地方都检查一下，基本上就不会漏掉问题。根据我的经验，国际化测试人员最喜欢的bug估计就是这种hardcode问题了，发现起来比较简单，一个产品中，一般情况下这类bug是最多的，比较容易凑数量，而且一旦发现就肯定会重现，验证起来也比较容易。

第二种hardcode的测试就比较麻烦，因为哪些地方容易出问题很难说，往往是靠经验积累的，所谓吃一堑长一智，就是靠大家在测试中不断地积累，整理一些相关的测试点，然后在测试过程中重点关注。有些问题如果不在特定的操作系统上进行测试，估计黑盒测试测一辈子都测不出问题。做国际化开发和测试的在分析系统功能时，要有国际化软件开发的意识，就是看到某个功能的描述，就能想到可能有哪些国际化的风险，这个也是在日常工作中慢慢积累的，其实这个和一般的测试类似，比如出现了翻页功能，那肯定要测试翻到最后一页和翻到第一页这两种情况类似。

过度翻译问题也是类似的，要靠经验积累，就是大家在用伪本地化build测试时要对字符串敏感，不要看到全部字符串加了前缀和后缀就高兴了，不是hardcode问题了。对字符串中的日期，路径之类的要特别关注，看看是不是特殊处理了。

自动化测试一直是一个比较热门的话题，我今天不是谈怎样去做自动化的框架或具体的自动化技术的细节，其实自己在这方面也只是个外行，今天主要谈一下自动化测试在国际化测试中应用的一些注意点。我所谓的自动化指的是基于GUI回放机制的功能自动化。
以我个人在自动化方面的经验，指望自动化工具去帮你发现测试遗漏的问题基本不可能，自动化需要测试的测试点基本上是从手工测试的用例中挑选的，在自动化测试中的检查点在手工测试用例中肯定都有,如果你的目的是靠自动化去发现问题，建议放弃这个打算。目前自动化测试应用基本上都是在做回归测试或者BAT(Build Acceptance Test)测试。

当维护一个已经比较成熟的产品时，如果经常需要对当前产品做一些小改动，测试人员往往关注的是改动的功能点测试，但是没有改动的部分就不会有问题吗？没有经过测试谁也不敢保证。如果每次改动都是很小的一部分，而其他功能的核心部分都需要重新测试一遍，测试人员的压力会相当大，而且这样重复的工作也会导致测试人员工作的积极性下降，如果对于产品的核心功能中绝大多数可以自动化的测试点进行自动化，测试人员在做测试时只重点关注改动的部分和各个功能之间有关联的部分，这样测试人员的精力将更集中，也可以花更多的时间去考虑改动对关联功能的影响，整个测试效率会大大提高，而且可以保证产品的核心功能没有问题。
另一种使用自动化的场景是BAT测试，我们在测试过程中经常会选择一些非常重要的测试用例作为BAT的case，如果这些case全部pass,我们才会进行下面的测试，如果这些Case中有一个或多个fail了，我们会要求开发人员重新出build,这些case的选择其实和维护产品过程中回归测试的核心功能测试case选择差不多。这样就出现了一个问题，我们测试人员拿到的build可能过不了BAT测试，而且有时候是连着几个build过不了BAT测试，这样会使测试人员产生抱怨，也影响大家工作的积极性，如果有可能的话，将这些BAT里面的Case做成自动化的Case,这样新build来的时候，自动化工具就可以帮你判断这个build是否有问题。如果没有问题，测试人员才进行正式的测试。

其实国际化的测试如果想去做自动化测试，也和上面两种情况类似，而且通常国际化需要自动化的case都是基于英文对应的自动化case进行修改或复用。我们现在是假设已经有了一套可以在英文上正常运行的脚本，怎么让他们能在本地化的操作系统上运行，以自动化测试工具QTP为例，首先，原来的自动化脚本是在英文操作系统上面运行的，你需要让脚本能在本地化的操作系统上面运行，其次，如果要支持本地化字符的输入输出，你就要将每一个和输入有关的地方都写在脚本里，比如输入框，下拉框的选择等，因为一般做BAT脚本时，输入框如果有默认值，一般会使用默认值，下拉框也是用默认值。如果你要测试输入本地化字符，用默认值肯定是不行的。
我们以第一个点为例，要保证脚本能在各种本地化操作系统上运行，这个其实和手工测试差不多，你要考虑哪些因素可能会影响脚本在本地化操作系统上运行，比如一般情况下软件默认会安装到C:\Program Files，但是德语等语言就不是这个目录，那么你的脚本就需要修改，当安装软件时脚本就要考虑不同的操作系统使用不同的默认安装路径。还有，对于messagebox等，在英文下显示为yes,no, 在中文会显示为是(Y),否(N)，还有一些其他类似的标准控件，他们都是实现了MUI的，在不同的操作系统下他们的text属性就不一样。如果你的对像识别属性中包含了text属性，脚本在本地化操作系统上运行就识别不了针对这些标准控件的操作，因为找不到对象，在QTP中，针对每一个需要测试的本地化的操作系统都必须有自己的object repository，你可以在英文的object repository基础上，使用update from application功能，直接去更新对象的属性就可以了。以上两个点是我在用QTP做国际化的自动化测试中感觉需要注意的地方。并不是所有的国际化测试点都适合用自动化来做的，比如UI上面的check,如果你去写脚本去check,脚本的check点会很多，维护也不好维护，成本太高，一般可以采用让QTP运行时将跑过的所有界面都抓图下来，然后人工检查的方式，你只要在options-->run里面设置Save still image captures to results 为always就可以了。这样通过运行时自动抓的图可以发现一些UI方面的问题。

其实在实际过程中也遇到过一些其他问题，有些可能是QTP自己对国际化支持的问题，比如一个输入框，脚本中有给其输入值的语句，在英文操作系统下跑没有问题，但是在日文操作系统下运行就有问题，通过回放脚本，你可以发现运行时有输入的动作，但是没有回车事件，这种情况就需要针对问题出现的问题进行特殊处理，这些实际上又都回到了自动化脚本的写法问题上，就不详细写了。至于其他的自动化测试工具如何来做国际化的测试，可能和用QTP有些细节的不同。但是我想核心的东西应该是一样的。

前面提到了一般程序的MUI测试，国际化里面还有一块是针对Web程序的MUI测试。测试方法是大同小异。
Web程序MUI有两种方式，一种是根据操作系统语言来显示对应的语言，然后用户可以在界面上选择换语言的方式来实现，这种方式在一般的程序MUI实现时也可能会遇到。也就是你选择选择什么语言系统就显示什么语言。因为你能选择的语言列表就是该软件支持的语言列表，该程序肯定要包含该语言列表里面的资源文件。

另外一种是根据浏览器的语言首选项来显示对应的语言.以常用的IE浏览器为例，进入Internet 选项--〉语言,在语言首选项里面大家一般看到的可能是中文或英文，这两种是根据大家操作的语言默认设置的，你可以添加一些其他语言，比如日语，韩语，德语等，所有添加的语言按照从上到下的顺序有一个优先级，当你去测试一个MUI的Web程序时，首先还是确定该MUI程序具体支持哪些语言和默认的语言，然后去语言首选项里面添加语言，比如把程序支持的语言放在第一位看是否正确显示对应的语言，把程序不支持的语言放在第一位，把程序支持的语言放在第二位，第三位等，去看程序是否用放在第二位的语言或第三位的语言去显示。 如果语言首选项里面的语言被测程序都不支持，那程序会用默认的语言比如英语来显示。 当把程序不支持的语言放在第一位，把程序支持的语言放在第二位，或之后，不同的软件需求可能不一致，简单一点的，如果语言首选项的第一位被测程序不支持，则直接用默认语言来显示，复杂一点的，遍历语言首选项，找到第一个被测程序支持的语言，然后用其显示，这个根据项目具体要求来看。

以上是针对Web程序的MUI测试总结。

MUI产品一般有两种方式，一种是一个安装包，安装包中包含了该产品支持的所有语言对应的资源文件，这种安装包的好处是只安装一次，缺点是安装包可能会比较大，因为包含了所有语言对应的资源文件。另一种形式是一个安装包加多个语言包的形式，用户可以在安装了英文产品后，根据自己需要来安装不同的语言包。这种形式的好处是安装包比较小，只包含自己需要的资源文件，缺点是语言包需要单独安装，但是两种形式的测试点大同小异。

测试MUI时首先要确定当前测试的产品具体要支持哪些语言,还要确定被测产品的默认语言是什么。所谓的默认语言就是当我们的被测产品没有当前操作系统的语言对应的资源文件时我们会自动选择使用哪种语言。在测试MUI产品时，一般都会使用支持MUI的操作系统进行测试。 MUI测试主要有以下几个方面:
1 将被测产品安装到某一个语言的操作系统上时(假设被测产品包含该语言对应的资源文件)，所有的字符串显示的语言都要使用和操作系统一致的语言。同时产品功能没有问题。功能测试是每一个测试点都需要保证的，测试时一般不会进行全面测试，只选择一些核心的功能点进行测试。
2 当操作系统的语言从语言A切换到语言B时(假设被测产品包含语言A和B对应的资源文件)，被测产品的所有字符串显示语言会从A切换到B
3 被测产品安装到操作系统上后，检查安装目录下包含了所有需要支持的语言对应的资源文件。一个MUI产品一般支持多个语言，测试时有可能没有足够的测试操作系统来逐一的对每种语言进行安装测试，这种情况下一般只检查是否包含了所有的资源文件。
4 将被测产品安装到一个该产品不支持的语言时，产品会显示它支持的默认语言。一般情况下默认语言为英语。

以上是工作中可能会用到的一些测试点，后面有时间再继续补充

国际化测试过程中经常会提到问题字符，顾名思义，所谓的问题字符就是当你使用它时会引起国际化问题的字符。

这里有一个关于问题字符的blog,针对不同的语言列举了一些问题字符，大家在测试过程中可以去使用。相当于一个测试数据集

http://blogs.msdn.com/b/michkap/archive/2007/06/12/3251648.aspx

关于问题字符，大家也可以参考以前的一个帖子。

http://bbs.51testing.com/thread-109540-1-4.html

今天谈谈国际化测试的第四级--双向文字识别能力
一般的国家，文字显示和界面布局现在都是从左到右的，从上到下的。但是像一些阿拉伯国家他们的文字和图像显示是从右到左的，如果想把产品卖到这些国家，还需要考虑支持从左到右和从右到左的显示问题。当系统的语言是英文或习惯从左到右显示的语言时，语言显示需要从左到右，如果是阿拉伯国家从右向左显示的话，我们的软件也要支持从右到左显示。
主要包括以下几个方面：
1 界面布局上的Frame
当我们把整个界面分为两块时，比如A和B,从左到右显示就是块A 块B,从右到左就是块B 块A
2 Frame中的控件，
包括对话框中的按钮顺序，横向滚动条和竖向滚动条的显示，标签的顺序，图片，导航显示，tab显示。
3 控件中的文字显示
各种控件中文字显示的方向也要支持从左到右和从右到左的显示。

目前我还没有参与过这种项目，还没有什么实际经验，以后有具体的经验后再对这部分进行补充。

前面我们已经谈到了国际化测试的两个级别，今天我们来谈国际化测试的第三级，使软件具备本地化能力

当一个软件已经可以满足国际化前面两个级别后，已经可以保证英文版本的软件在各种平台上运行了.如果还准备发布针对不同国家的本地化版本，我们还需要软件有一定的可本地化能力。当软件具有了可本地化能力后，本地化的工程师基本上不需要对代码进行改动，只需要去翻译资源文件就可以了。

第一点是要保证我们的代码里字符串不能被硬编码。
我们在国际化第一级里面也提到过硬编码，那种硬编码和国际化第三级的硬编码有点区别，在国际化第一级的硬编码主要是一些系统变量被硬编码后引发的系统功能问题，在国际化第三级里面的硬编码，主要是针对一些需要显示给用户的界面上的字符串，错误消息框，日志，图标上的问题等，这些字符串都需要提取到资源文件里。如果没有提取到资源文件里面，而是遗漏在代码中，那么本地化后的软件可能出现有些字符显示的是本地化的文字，有些地方是英文。如果要修改这样的问题，是需要修改代码的。测试这种问题没有什么好方法，也没有什么技巧，主要是要对系统业务熟悉，力争测试到每一个界面。不过，好像现在也有一些开发人员可以写一些工具来检查代码中是否有硬编码,可以减少漏测的风险

第二点是要保证所有显示字符串的控件要进行一定的空间扩展
当英文句子翻译为其他语言时，长度一般都会发生变化，当翻译后的字符串长度增加时，就造成字符串在空间中显示不完整的问题，比较轻微的用户还可以看到大部分句子，知道显示的是什么意思，严重的话可能就看到句子里面的几个字，根本不知道要做什么。

第三点是在代码中避免使用字符串的连接。
就是一个你要显示给用户的句子要放在一个字符串里，不要根据判断条件去组合句子，
例如：str="You can";
      if(condition==true) str+="not"
      str+="delete this object"

出现这种情况,本地化工程师将很难结合上下文去翻译字符串.

第四点是不能硬编码字体和字体的大小。
在不同的操作系统上字体可能是不一样的，如果硬编码了字体，有些本地化的字符是没办法显示的。默认的字体大小也是不一样的，例如日文操作系统上的字体感觉要比其他的大一些。如果硬编码字体和字体的大小，会引起文字显示的问题。

第五点是尽量将控件放在句子的开头或结尾，不要将控件放在句子中。如果将一个控件例如下拉框放在句子中间，就意味着控件两边有两个string,由于翻译后可能造成词语顺序颠倒，本地化工程师翻译时有可能翻译的不正确，不能完全表达句子的意思.

第六点是过度本地化,将一些不需要本地化的内容放入到了资源文件中,而且没有注释告诉本地化工程师.导致本地化工程师将不需要翻译的东西翻译了,引发问题.