Joh*_*ney 44 language-agnostic unicode localization internationalization
您是如何在已经参与的实际项目中实施国际化(i18n)的？
在我阅读Joel的着名文章之后,我开始兴趣制作软件跨文化,绝对最低限,每个软件开发人员绝对必须知道Unicode和字符集(没有借口!).但是,除了确保我尽可能使用Unicode字符串之外,我还没有能够在一个真实的项目中利用它.但是将所有字符串设置为Unicode并确保您了解所使用的所有内容的编码只是i18n冰山的一角.
我迄今为止所做的一切都是由一群受控制的美国英语人士使用,或者在推动项目实施之前我们没有时间去做.因此,我正在寻找人们在实际项目中使软件更加本地化的任何提示或战争故事.
McD*_*ell 47
已经有一段时间了,所以这并不全面.
字符集
Unicode很棒,但你无法忽略其他字符集.Windows XP(英语)上的默认字符集是Cp1252.在网络上,你不知道浏览器会发送给你什么(虽然希望你的容器能够处理大部分内容).当您使用的任何实现中存在错误时,不要感到惊讶.当字符集移动到机器之间时,它们可以与文件名进行有趣的交互.
翻译字符串
一般来说,译者不是编码员.如果您将源文件发送给翻译者,他们将破坏它.应将字符串提取到资源文件(例如Java中的属性文件或Visual C++中的资源DLL).译者应该获得难以打破的文件和不会让他们破坏的工具.
翻译人员不知道产品中字符串的来源.没有上下文很难翻译字符串.如果您不提供指导,翻译质量将受到影响.
在上下文的主题中,您可能会多次出现相同的字符串"foo",并认为让UI中的所有实例指向同一资源会更有效.这是一个坏主意.在某些语言中,单词可能对语境非常敏感.
翻译字符串需要花钱.如果您发布新版本的产品,则恢复旧版本是有意义的.有工具从旧资源文件中恢复字符串.
字符串连接和字符串的手动操作应该最小化.使用适用的格式函数.
翻译人员需要能够修改热键.Ctrl+ P是英文版; 德国人使用Ctrl+ D.
如果您的翻译过程需要有人随时手动剪切和粘贴字符串,那么您就会遇到麻烦.
日期,时间,日历,货币,数字格式,时区
这些都可能因国家而异.逗号可用于表示小数位.时间可能是24小时的表示法.不是每个人都使用格里高利历.你也需要明确无误.如果您注意在您的网站上显示美国的MM/DD/YYYY日期和英国的DD/MM/YYYY日期,除非用户知道您已完成日期,否则日期不明确.
特别是货币
类库中提供的Locale函数将为您提供本地货币符号,但您不能只在一个以美元计算价格的值前面加上一英镑(英镑)或欧元符号.
用户界面
布局应该是动态的.不仅字符串在翻译时可能会翻倍,整个UI可能需要反转(希伯来语;阿拉伯语),以便控件从右向左运行.那是在我们到达亚洲之前.
翻译前的测试
非技术问题
有时你必须对文化差异敏感(可能导致进攻或不理解).您经常看到的一个错误是使用标志作为选择网站语言或地理位置的视觉提示.除非你希望你的软件在全球政治中宣布方面,否则这是一个坏主意.如果你是法国人并且提供英国圣乔治国旗的选项(英国国旗是白色领域的红十字会),这可能会导致许多说英语的人感到困惑 - 假设外语和国家会出现类似的问题.图标需要经过审查才能具有文化相关性.竖起大拇指或绿色勾号是什么意思？语言应该是相对中立的 - 在一个地区以特定方式对待用户可能是可以接受的,但在另一个地区则被认为是粗鲁的.
资源
C++和Java程序员可能会发现ICU网站很有用:http://www.icu-project.org/
Mic*_*tum 15
一些有趣的事情:
拥有适用于德语和法语的PHP和MySQL应用程序,但现在需要支持俄语和中文.我认为我将其移至.net,因为PHP的Unicode支持是 - 在我看来 - 并不是很好.当然,使用utf8_de/encode或mbstring-functions来玩杂耍很有趣.几乎和弗雷迪克鲁格一样在晚上拜访你一样有趣......
意识到某些语言比其他语言更加冗长.德语通常比英语更冗长,并且看到德语版本如何破坏用户界面,因为分配的空间太少并不好玩.有些产品凭借Oblivion的"Schw.Tr.d.Le.En.W."以其创造性的方式获得了一些成名.令人难忘:-)
玩弄日期格式,哇哦!是的,世界上实际上有些人使用日期格式,其中一天在中间.尝试找出07/02/2008应该是什么意思,因为有些用户可能认为它可能是7月2日,所以很有趣...但话说回过头来,你们在池塘里的人们可能会相信那些放置了中间的一个月:-P,特别是因为在英语中,7月2日听起来比7月2日好很多,有些东西不一定适用于其他语言(例如德语,你永远不会说Juli 2但总是Zweiter Juli).尽可能使用2008-02-07.很明显,它意味着2月7日它正确排序,但dd/mm与mm/dd可能是一个非常棘手的问题.
Anoter有趣的东西,数字格式!10.000,50 vs 10,000.50 vs. 10 000,50 vs. 10'000,50 ......这是我现在最大的噩梦,不得不支持多元文化的环境但没有任何方法可靠地知道用户的数字格式将使用.
正式或非正式.在某种语言中,有两种方式可以解决人,一种是正式的方式,一种是非正式的方式.在英语中,你只说"你",但在德语中你必须在正式的"Sie"和非正式的"Du"之间做出决定,同样适用于法国的Tu/Vous.选择正式方式通常是一个安全的选择,但这很容易被忽视.
日历.在欧洲,本周的第一天是星期一,而在美国则是星期天.日历小部件很不错.在欧洲用户的左边和星期六显示一个日历,周日是不太好的,它会让他们感到困惑.
我曾为我以前雇主使用过.NET的项目工作,我们使用了内置的.resx格式.我们基本上有一个文件,其中包含.resx文件中的所有翻译,然后是具有不同翻译的多个文件.这样做的结果是,您必须非常勤奋地确保应用程序中可见的所有字符串都存储在.resx中,并且无论何时更改,您都必须更新所支持的所有语言.
如果您变得懒惰并且没有通知负责翻译的人员,或者您没有通过本地化系统嵌入字符串,那么稍后尝试修复它将是一场噩梦.同样,如果本地化是事后的想法,那么就很难实施.最重要的是,如果您没有将所有可见字符串存储在标准位置的外部,则很难找到所有需要本地化的字符串.
另外一点,非常严格地避免直接连接可见字符串,例如
String message = "The " + item + " is on sale!";
相反,你必须使用类似的东西
String message = String.Format("The {0} is on sale!", item);
这样做的原因是不同的语言经常以不同的方式对单词进行排序,并且直接连接字符串将需要一个新的构建来修复,但如果您使用某种类型的字符串替换机制,则可以修改.resx文件(或任何本地化)您使用的文件)用于需要重新排序单词的特定语言.