英文伪原创(中文名伪翻译编辑锁定讨论上传视频伪的方法)

　　英文伪原创(中文名伪翻译编辑锁定讨论上传视频伪的方法)

　　伪翻译编辑器锁讨论上传视频

　　伪翻译是

　　软件测试

　　用于测试软件是否匹配国际化和本地化的方法之一。用于测试软件国际化方面的软件测试方法。不是在本地化过程中将软件的文本翻译成外语，而是将应用程序的文本元素替换为原创语言的更改版本。

　　中文名

　　伪翻译

　　外国名字

　　伪定位

　　也被称为

　　伪本地化

　　如果软件的设计没有考虑到本地化，那么

　　本地化翻译

　　，你可能会面临很多问题。例如，翻译后的文本可能比源语言中的文本长，这会导致翻译后的文本被截断，难以识别。比如软件菜单、文本区域、按钮、复选框等，设计人员在设计界面时通常会调整适合源语言文本长度的大小（通常是英文），并进一步调整对齐方式、位置、行距等。但是，有些语言从源语言翻译过来后，往往源语言的长度比源语言的长度要长。例如，德语或挪威语通常比英语长，所以原来的界面尺寸会太小而无法正常使用。显示翻译的文本。

　　问题可能比较严重，某些语言的文字或符号可能是软件原名造成的。

　　字形

　　不支持，所以无法正常显示。问题也会出现在输入端。一些程序员错误地认为用户在输入时不会输入特定语言的一些特殊字符或单词，从而导致用户在实际操作软件时出现问题。

　　对于一些成熟和大多数

　　目标语言

　　对于已经可以翻译的软件，或者只是界面改动很少的软件，将翻译应用到软件上，多语言测试，可能是直接测试软件的最直接也是最好的方法。对于一些新开发的软件，或者接口变化较大的软件，翻译完成后等待接口测试可能会耽误整个测试进度。而且，在软件开发的早期，界面文本的翻译不一定就开始了，因为界面有很大的机会进行调整甚至重新设计。如果等到产品比较成熟才开始翻译接口，再进行翻译的接口测试，可能会耽误产品的上市时间。

　　伪本地化

　　将是最好的选择，原因之一包括翻译实际上没有运行。

　　一般来说，程序中预期翻译的文本将是

　　伪翻译

　　（伪翻译）。假设英语是软件的源语言，一般来说

　　伪翻译

　　文本必须比源语言中的文本长，文本必须收录不带空格的长词，并且最好收录不同的

　　语系

　　的

　　单词

　　. 这样，测试人员可以通过查看每个界面的组件来验证文本是否被截断。

　　[1]

　　传统上，软件的本地化独立于软件开发过程。在典型的场景中，软件将使用基础语言（例如英语）进行构建和测试，并将任何可本地化的元素提取到外部资源中。这些资源被移交给本地化团队以翻译成不同的目标语言。这种方法的问题在于，在本地化过程中可以发现许多细微的软件错误，因为修复它们为时已晚（或更可能过于昂贵）。

　　本地化过程中可能出现的问题类型涉及书面文本在不同语言中的显示方式不同。这些问题包括：

　　此外，本地化过程可以揭示哪些元素应该是可本地化的，但在源语言中是硬编码的。类似地，可能有一些元素被设计为本地化，但不应该是本地化的（例如 XML 或 HTML 文档中的元素名称。）

　　伪本地化旨在通过将所有可本地化元素机械地替换为源语言使用者可读但收录其他语言和脚本的大部分麻烦元素的伪语言来捕获开发周期中的这些类型的错误。这就是为什么伪本地化被认为是一种工程或国际化工具而不是本地化工具的原因。

　　Microsoft Windows 中的伪翻译伪本地化编辑

　　在 Windows Vista 开发周期中，Microsoft 引入了伪位置。为此目的发明的伪语言类型在 Windows 用语中称为伪语言环境。这些语言环境旨在使用 Windows 字符集和脚本功能在时基（“西方”）、镜像（“近东”）和 CJK（“远程”- 一在“东方”中使用的三个主要外语类别中）。在 Vista 之前，这三种语言中的每一种都有自己独立的 Windows 版本，可能具有不同的代码库（因此，不同的行为和错误）。为每个语言家族创建的伪语言环境仍然会产生“读取”的 Text。英语，但由其他语言的脚本组成。例如，文本字符串

　　编辑程序设置

　　将在“基础”伪语言环境中呈现为

　　[！！！εÐiţ Þr0ģЯãm səTτıИğ§ !!!]

　　此过程生成长转换字符串，包括非 ASCII 字符，并且（在“镜像”伪语言环境的情况下）从右到左书写。

　　请注意，此示例中文本周围的括号有助于发现以下问题：

　　截断文本（截断）

　　通过组合（连接）形成的字符串

　　不可本地化的字符串（硬编码）

　　Michael Kaplan（Microsoft 项目经理）解释了伪本地化过程，类似于：

　　一个热心、勤奋但天真的本地化实习生，渴望证明她 [或她自己] 以及任何将翻译你不说的每一个字符串的人都不应该被翻译。

　　伪定位过程的一个关键特征是它在开发周期中作为例程构建的一部分自动发生。该过程与用于生成真正本地化构建的过程几乎相同，但在构建测试之前，在开发周期的早期完成。这为在基本代码中发现的任何错误留出了时间，比直到发布日期临近才发现的错误要容易得多。

　　伪本地化过程产生的构建使用与非本地化构建相同的 QA 循环进行测试。由于伪语言环境模仿英文文本，因此可以由说英语的人进行测试。Windows 版本（7 和 8） 已发布，其中一些伪本地化字符串完好无损。对于这些最新版本的 Windows，伪本地化版本是主要的临时版本（通常用于测试的版本），最终的英文版 build 是该版本的“本地化”版本。

　　除了 Microsoft 内部使用的工具外，其他国际化工具还包括伪位置选项。这些工具包括 Alchemy Software Development 的 Alchemy Catalyst、SDL 的 SDL Passolo 和 g11n 的 Globalyst。这些工具包括伪本地化功能，包括查看呈现的伪本地化对话框和自动化测试过程本身的能力。虽然像 Globalyst 这样的工具会完成创建伪本地化构建和自动化测试的整个过程，但它也可以通过在提取的文本资源上运行自定义伪本地化脚本并手动测试来完成。

　　网上有各种免费的伪定位资源，可以创建常见本地化格式的伪本地化版本，如iOS字符串、Android xml、Gettext po等。这些网站（like和Babble-on）允许开发者上传字符串文件到网站并下载生成的伪本地化文件。

　　本页未经许可抄自百度百科

　　参考