我读过Joel关于Unicode的文章,我觉得从字符集的角度来看,我至少掌握了国际化的基本知识.除了阅读这个问题之外,我还做了一些关于设计考虑的国际化研究,但是我不禁怀疑还有更多我不知道或者不知道的东西.不知道要问.
我学到的一些东西:
有些语言从右到左而不是从左到右阅读.
日历,日期,时间,货币和数字的显示方式因语言而异.
设计应该足够灵活,以容纳更多的文本,因为有些语言比其他语言更冗长.
当涉及到它们的语义时,不要把图标或颜色视为理所当然,因为这可能因文化而异.
地理命名因语言而异.
我在哪里:
我的设计非常灵活,可以容纳更多文字.
我自动翻译每个字符串,包括错误消息和帮助对话框.
我还没有到达需要显示时间,货币或数字单位的地方,但我很快就会在那里,需要开发一个解决方案.
我正在全面使用UTF-8字符集.
我的菜单和应用程序中的各种列表按字母顺序排列,以便于阅读.
我有一个标记解析器,通过过滤掉停用词来提取标签.停用词列表是特定于语言的,可以换出.
我想更多地了解:
我正在开发一个可下载的PHP Web应用程序,因此非常感谢有关PHP的任何具体建议.我已经开发了自己的框架,并且目前对使用其他框架不感兴趣.
我对非西方语言知之甚少.我上面没有提到需要考虑的具体考虑因素吗？另外,PHP的数组排序函数如何处理非西方字符？
你在实践中遇到过任何具体问题吗？我正在考虑GUI和应用程序代码本身.
有关处理日期和时间的任何具体建议吗？根据地区或语言是否有细分？
我已经看到很多项目和网站让他们的社区为他们的应用程序和内容提供翻译.您是否建议这样做以及确保您有良好翻译的一些好策略？
这个问题基本上就是我对国际化的了解程度.什么我不知道我不知道我应该进一步研究？
编辑:我添加了赏金,因为我想从经验中获得更多真实世界的例子.
我们的游戏Gemsweeper已被翻译成8种不同的语言.我在这个过程中学到的一些东西:
如果译者被给予单个句子进行翻译,请确保他知道每个句子的使用情况.否则他可能提供一个可能的翻译,但不是你想要的翻译.诸如Babelfish之类的工具在不理解上下文的情况下进行翻译,这就是为什么结果通常如此糟糕.试着将任何非平凡的文本从英语翻译成德语并返回,你会看到我的意思.
出于同样的原因,不应将应翻译的句子分成不同的部分.那是因为你需要维护上下文(见前一点),因为某些语言可能在句子的开头或结尾有变量.使用占位符而不是分解句子.例如,而不是
"这是我们的15步教程的一步"
写下类似的东西:
"这是我们的15步教程的第1步"
并以编程方式替换占位符.
不要指望译者有趣或有创意.除非你给特定的文字段落命名并额外付费,否则他通常没有足够的动力去做.例如,如果您在语言资产中有笑话,请在旁注中告诉译者不要尝试翻译它们,而是将它们排除在外或用更严重的句子替换它们.否则翻译人员可能会逐字翻译笑话,这通常会导致完全无意义.在我们的案例中,我们有一个翻译和一个笑话作家,用于最重要的翻译(英语).
尝试找到一个翻译人员,他的第一语言是他要翻译你的软件的语言,而不是相反.否则他可能会写一个可能正确的文本,但对母语人士来说听起来很奇怪或过时.此外,他应该与您的翻译目标居住在您所在的国家/地区.例如,来自瑞士的讲德语的人不会是德语翻译的好选择.
如果有可能,请让您的一位公共beta测试用户了解特定翻译,以验证已翻译资产和已完成的软件.我们有一些非常好的和非常差的翻译,取决于提供它的人.根据我们的一些用户的说法,瑞典语翻译完全是胡言乱语,但对它做任何事都为时已晚.
请注意,对于具有新功能的每个更新版本,您都必须翻译您的语言资产.这可能会产生一些严重的开销.
请注意,如果您的软件已翻译,最终用户将希望技术支持能够说出他们的语言.再一次,Babelfish很可能不会这样做.
编辑 - 还有一些要点
尽可能简化本地化之间的切换.在Gemsweeper中,我们有一个热键可以在不同的语言之间切换.它使测试更容易.
如果要使用外来字体,请确保它们包含特殊字符.我们为Gemsweeper选择的字体适用于英文文本,但我们必须手工添加相当多的字符,这些字符仅存在于德语,法语,葡萄牙语,瑞典语,...
不要编写自己的本地化框架.使用像Gettext这样的开源框架,你可能会好得多.Gettext支持句子中的变量或复数等功能,并且非常坚固.编译本地化资源,因此没有人可以篡改它们.此外,您可以使用像Poedit这样的工具来翻译文件/检查其他人的翻译并确保所有字符串都已正确翻译,并且在您更改基础源代码时仍然是最新的.我已经尝试过自己滚动并使用Gettext而不得不说Gettext加上PoEdit是优越的.
编辑 - 更多点
了解不同的文化有不同的数字和日期格式.编号方案不仅在每种文化方面都有所不同,而且在该文化中也是不同的.在EN-US中,您可以格式化数字'-1234'; '-1,234'或(1,234)取决于数字的目的是什么.了解其他文化做同样的事情.
了解您从哪里获取全球化信息.例如,Windows具有CurrentCulture,UICulture和InvariantCulture的设置.了解每个人的意义以及它与您的系统的交互方式(它们并不像您想象的那么明显).
如果你要做东亚翻译,那就做你的功课吧.东亚语言与语言有很多不同之处.除了具有同时使用的多个字母表之外,它们还可以使用不同的布局系统(自上而下)或基于网格.东亚语言中的数字也可能非常不同.在en-US中,您只能在有限条件下更改系统(例如1对1),除了逗号和句点之外还有其他数字注意事项.
我的菜单和应用程序中的各种列表按字母顺序排列,以便于阅读.
列表应该排序,菜单不应该排序.请记住,给定的用户可能希望以多种语言使用您的应用程序,他仍然应该在同一个地方的任何地方找到它.
与快捷方式相同,如果你有任何:不要翻译它们.
另外,请记住,国际化和翻译是两个截然不同的事情,分别管理它们.
当我们处理Dreamfall和柯南时代的i18n/l10n问题时,我们遇到了一些值得记住的问题.其中一些我们解决了,一些是为我们解决的,一些我们解决了.有些我们从未解决过......
确保您的所有工具和所有代码都支持您要使用的所有字符集,并在项目过程中再次检查该假设两次,并确保更多次.
确保使用支持您要使用的所有语言的字体.声称为unicode的大多数字体只是unicode,因为它拥有的字符位于正确的代码点.这并不意味着它对所有代码点都有可用的字符.
文本包装不仅在空格中完成,因为某些语言不使用空格来分隔单词(中文浮现在脑海中).确保文本换行例程处理文本时没有任何空格.
正确处理复数在简单的情况下是棘手的,并且在困难的情况下很难.确保您对将要使用的语言有足够的了解,以便能够编写代码来正确处理复数问题.请记住,英语(和其他"西方"语言是容易的.
永远不要打破句子并用它们构建字符串以适应变量,因为变量可能以不同的语言放在句子的其他地方.使用占位符.
请记住,对于某些语言,占位符的值可能会更改如何编写句子.语法很难.确保你有一个处理它的计划.(具体来说,请确保您有一种方法可以根据性别,时间等对您在占位符中使用的值进行分类).
我想做出以下评论 - 这些评论来自一些公司指南,其中第1类产品在31种不同的语言环境中进行翻译.遵循这些指导方针为我们(我们的开发团队而不是整个公司)提供了最高的翻译效率.
不要尝试重用错误消息的片段.例如,不要以为因为你有两个错误"You selected the wrong menu item"并且"That menu item is not yet available",可以提取"menu item"到一个单独的项目,并在两地使用.所有消息都应自包含,因为它们的翻译可能会根据上下文而改变
使用熟悉技术的专业翻译人员.如果你去接近像BabelFish这样的服务,你将得到你应得的一切.例如,"Microsoft Windows"是"Microsoft Windows"无处不在地球上,它不会成为"Microsoft Fenster"在德国.
尽量不要嵌入变量内的信息(如"The %1 has failed"这里%1因为位置的变化动态),而事实上,两性均可发生变化:"La table est rubbish"对"L'Homme est drunk",或者"The red table"VS "La table rouge".最好使用附加参数的通用名词:"The item has failed [%1]".
仅翻译用户期望看到的内容.日志文件中的日志消息(只有您将使用)应该是英语(或您的母语),而不是翻译成您无法读取的斯瓦希里语.
菜单应按功能排序,而不是按整理顺序排序.
可翻译单元应存储在代码外部并在运行时加载.这使得翻译成为一个只关闭外部文件的问题,而不是试图将更改转变为代码中间.它还使得将来更容易添加其他语言.
这就足够了.最好在你睡着之前停下来:-)
关于数字的事情:在英语中,据我所知,你只使用1和1的复数和2或更多的复数.喜欢:"你有1条消息"; "2条消息"; "3 ...消息".在俄语中,这些事情变得更加复杂.你使用单数为1,21,31,41 ... 101,121(因此,对于以1结尾的所有内容,除非它以11结尾).然后你使用奇异的格式 2,3,4; 22,23,24; 32,33,34 ...... 102,103,104; 122,123,124.在所有其他情况下,你使用复数的属格案例.
实施起来并不难.什么是辛苦,虽然是实现的东西,就会知道如何应对其所有的怪事任何先验未知的语言:-)
这只是数字:-)
到目前为止,我没有很多东西可以添加到最好的答案中,但这里有一些需要考虑和检查的事情.
不要做出假设. 这是所有规则.很容易假设区域或语言特定的东西,很难注意到这些假设.
对字符串比较要非常小心. 有一些语言,例如土耳其语,其字母与其他语言在视觉上相似但不同.
使用伪翻译作为冒烟测试. 如果您从资源文件中读取已翻译的字符串,请创建该文件的伪翻译版本,这对您来说仍然是可以理解的,但会强调应用程序中每个可翻译字符串的容量和功能.例如,用"CancelXXXX!"之类的东西填充像"取消"这样的字符串.因此它与翻译字符串的宽度一样宽.然后,您可以测试以验证每个字符串是否将完全显示.额外的功劳还包括可能被渲染的最复杂的角色,以验证它在所有地方都能正确显示.
不要对键盘布局做出假设. "ASDW"可能是用于QWERTY键盘的一组很好的方向键控制,但是硬编码使得对其他键盘布局的人使用它(如果不是不可能的话)是不友好的.
测试各种日期设置,然后再次测试它们. 我看到的问题是由于区域设置中"AM/PM"的格式不同.mm/dd/yyyy与dd/mm/yyyy也出现了很多,但这里的每个设置都很重要.
测试各种数字格式,然后再次测试它们. 例如,您不想依赖小数或千位分隔符.
使用和不使用用户登录服务器进行测试. 这可能更具特定于Windows,但很容易在服务器上配置一个组件,以便在用户登录时使用登录用户的区域设置,并在用户未登录时使用默认区域设置.会导致奇怪的,间歇性的行为.
使用各种区域和语言设置进行测试. 例如,Windows不仅具有区域和语言设置,而且IE还有自己的语言设置.例如,首先列出en-us的IE客户端的行为可能并不总是与首先列出的en-nz的行为相同.
确保您的翻译人员了解业务和语言,然后与其他人进行交叉核对. 每次使用特定于应用程序的术语时都要非常小心.如果您的程序使用特定的单词来表示应用程序中的特殊内容,请确保它们在每个实例中都以类似的方式进行翻译,包括在帮助文本中.如果您有特定的语言目标,您甚至可以提前翻译这些单词,并确保它们不会在目标语言中翻译得不好.这更像是一个产品研究的东西,但它可以改变界面中使用的单词,如果这些单词从一开始就适用于每个人,那就更容易了.你也想避免可能翻译不好的习语.
好吧,我还有更多的话要说...
有一件事我学到了很多困难:如果你有几个需要翻译的文件,在名称中包含一个额外的标签,以便以后你可以在整个文件夹中搜索该标签.
例如,不是命名文件'sample-database.txt',而是命名英文版'sample-database-loc-en.txt',意大利语版本'sample-database-loc-it.txt
京公网安备 11010802040832号 | 京ICP备19059560号-6 
