Questions tagged «internationalization»

国际化(i18n)是设计软件应用程序的过程,因此无需进行工程更改即可使其适应各种语言和地区。

12
.NET中有效的本地化策略[关闭]
我正在为.NET MVC应用程序开发UI,在不久的将来它将要求所有内容的国际本地化。我对.NET总体上非常熟悉,但是从来没有一个项目需要如此高度地关注国际可访问性。 该项目最初是用英语完成的。在这一点上,我应该采取什么措施来简化将来的本地化工作?

6
如何正确定位数字?
在前端应用程序中本地化数字时应注意哪些注意事项? 示例:在巴西葡萄牙语(pt-BR)中,我们用点分隔小数,用逗号分隔小数。在美国英语(en-US)中则相反。在pt-BR中,我们显示以千位分隔的数字,与en-US相同。但是,今天阅读有关印度英语(en-IN)的信息时,我偶然发现了这个宝石: 印度编号系统是数字分组的首选。用文字或口语表达时,小于100,000 / 100 000的数字与标准英语中的数字相同。在印度编号系统的子集中表示的数字包括100,000 / 100000以上。 https://zh.wikipedia.org/wiki/Indian_English#Numbering_system 意思是: 1000000 units in pt-BR are formatted 1.000.000 1000000 units in en-US are formatted 1,000,000 1000000 units in en-IN are formatted 10,00,000 除了逗号和点以及其他特定的分隔符外,似乎遮罩也是一个有效的问题。 在前端应用程序中本地化数字时,我还应该注意哪些其他警告?特别是如果我要向非拉丁字符集显示数字?

12
号码本地化是否不必要?
我刚刚阅读了此页面http://weblogs.asp.net/scottgu/archive/2010/06/10/jquery-globalization-plugin-from-microsoft.aspx 他们所做的一件事是将阿拉伯日期转换为阿拉伯日历。我想知道这样做是否是个好主意。对于用户而言,它实际上是否会令人讨厌/困惑(即使用户是阿拉伯人)。 另外,我的第二个问题是,对于某些文化(例如德语),我们真的需要将33,899.99更改为33.899,99吗?我的意思是这样做没有什么害处,因为该库已经为我们做到了,但这实际上不会给用户带来更多混乱(即使他是德国人,等等)。 我敢肯定,这些人来自什么文化,如果我给您一个数字33,899.99,您将不可能正确地猜对吗?(除非我的网站/应用程序是您一生中使用过的第一个网站/应用程序,可以说这是可能的,但可能性很小) 我的意思是“通用”,这是每个人都会看到并知道其含义的格式。它不一定是用黑白之类的东西编写的标准。只要每个人都可以阅读并直接知道文本所代表的含义,那就很普遍了。可以肯定的是,1.234,00绝对不是通用的。我的意思是,我非常确定您可以找到一生中一直在使用计算机但从未遇到过这种数字格式的人。由于大多数网站/应用程序一直在使用1,234.00而不进行任何更改以适应本地化,因此我相信这已成为事实(每个人都会看到并知道它的含义的通用格式)。 至于日期,如果我们写03/01/02,我敢肯定,没有人会知道(马上,马上,没有歧义)今天是几号。但是如果我们将它们写成这样,没有人能弄错2003年1月2日,2003年2月1日,2001年2月3日不是吗? 顺便说一句,这个问题是针对本地化的,不要告诉我“嘿,不是每个人都懂英语!”之类的东西。因为那是国际化的问题(这超出了本主题)。让我们坚持关于本地化的讨论。

6
一个电话号码应允许使用哪些特殊字符?
因此,我正在设计一个供全球用户使用的网页,其中包括来自加拿大,美国,印度,英国等地的用户。我需要对此电话号码字段进行验证,但是我不确定执行此操作的最佳方法。 我能想到的一些有效格式是: 1800123456(印度) 美国电话号码中使用“-” 我对应该允许用户输入哪些特殊字符感到困惑(例如- / ())。过去其他人如何解决这个问题?

4
为什么通常将字符串资源保留在代码外部而不是代码内部?
通常,在许多平台上,我都将字符串资源写入.resx或.xml文件,然后使用某种依赖于平台的方法来获取它们。 也就是说,在iOS上,我通过NSBundle.MainBundle和Context.Resources在Android上使用来获取它们。 这种方法的优点是什么,为什么不直接在代码中访问它,例如: 在跨平台项目中,任何平台都可以直接访问它,而无需集成。 在构建过程中,无需担心资源是否构建良好。 编码人员可以使用多种语言处理功能 长话短说:以这种方式构造字符串资源的原因是什么? [编辑] 假设我的文件是其他项目之间共享的“核心”项目的一部分。(考虑一下PCL跨平台项目文件结构。) 并假设我的文件与.resx / .xml文件完全相似,看起来像这样(我不是xml专业人士,对不起!):参数Paramètres 因此,这基本上是一个自定义xml,您在其中指向键/语言以获取正确的字符串。 该文件将成为应用程序的一部分,就像您在应用程序内添加任何可访问文件一样,并且系统将访问使用PCL编码的字符串资源。这会增加应用程序的开销吗?

5
如何组织本地化字符串资源?
我们正在开发一个包含许多小程序包的大型应用程序。每个软件包都有自己的一组资源文件以进行本地化。 组织和命名本地化字符串的最佳方法是什么? 到目前为止,这是我的想法: 处理重复项 同一文本(例如“邮政编码”)在给定的程序包中可能多次出现。编程本能(DRY)告诉我创建一个由所有实例共享的单个字符串资源。 再者,翻译者可能希望在某些地方选择长译本(“ Postleitzahl”),在空间较小的地方选择短译本(“ PLZ”)。或者,我们可能决定在某些情况下添加冒号(“邮政编码:”),而在其他情况下则不添加。或者我们可能在某些地方要求使用不同的大写字母(“邮政编码”)。所有这些参数都指向每种用法创建一个资源,即使它们的内容相同。 命名 如果我们希望消除重复,则可以按内容命名资源,也许可以通过前缀提示使用的种类。因此,我们可能有labelOK= “ OK”,messageFileTooLarge= “文件超出了最大文件大小。” 和labelZipCode= “邮政编码”。 按内容命名具有自然处理格式参数的优势:资源messageFileHas_0_MBWhileMaximumIs_1_MB显然采用两个格式参数,即实际文件大小和最大文件大小。 但是,如果我们允许重复,则仅按内容命名是没有意义的。为了获得唯一的资源名称,我们必须以某种方式在资源名称中包括使用位置。这适用于图形控件,尽管标识符往往有点长:fileSelectionConfirmationButtonText= “ OK”,customerDetailsTableColumnZipCode= “邮政编码”。但是,对于非可视代码文件,它会变得更加困难。如果您不知道字符串的最终显示位置,该如何命名字符串的特定用法?通过代码文件和函数名称?对我来说似乎很笨拙。 总而言之,我倾向于允许重复,但是我一直在努力寻找一个支持此目的的一致命名方案。 编辑:这个问题有两个方面:如何组织资源(DRY与重复项)以及如何命名它们。到目前为止,答案集中在第一方面。非常感谢您提供有关命名约定的反馈!

1
对于嵌入式系统项目,包含东南亚字符集的绝对最低要求是什么?
我为一家已经开始将嵌入式计算机系统集成到我们生产的产品中的公司工作。我们拥有种类繁多的产品,它们遍布全球。此外,我们还设计了一些集成板,可以根据已刷新到系统的固件来满足多种目的。这样,我们不必为各种产品重新设计计算机硬件-我们要做的就是重写固件层来满足特定产品的需求。 由于这些硬件限制,更改我们的硬件需要采取一些行动,但是编写新软件要简单得多。 我们的产品之一有一个我们以前没有实现过的新要求,那就是需要用户输入文本。 当前,我们已经能够在资源中存储国际文本,并且只有必要的字体字符才被编译为位图图像。这意味着我们已经能够在最小的空间中存储像中文和日语文本这样的高表意语言,因为我们只使用了整个语言集中很小的一部分。 由于此新产品将要求我们的用户输入文本,因此我们将必须实现广泛的字符集。作为主要的PC开发人员,我对ASCII,Unicode,UTF-8等非常熟悉,但是,由于我们板上的FRAM数量有限,因此无法实现所有这些语言的完整字符集存储字体数据。 我的管理层希望能够使用最少的字符集来用于高度表意的语言。我相信日语(平假名?)也有语音字母。汉语,韩语,越南语等语言也有相似的语音字母吗?我很确定该问题的答案是“绝对,不是”,但这是一个值得询问的问题。 管理层提出了“软”要求,即我们只能使用大约8,000个字符的有限字符集来覆盖所有常用的主要语言。如果这不可能,我们需要根据有限的硬件资源寻找某种形式的替代方法来满足我们的需求。 我确信这个问题以前必须已经解决。是否有人需要在这样的约束下工作,同时又需要广泛的字体和字符编码系统的经验?如果是这样,您可以提供哪些智慧?

8
您在开发时会考虑本地化吗?
在开发软件项目或网站时,您是否考虑到本地化? 我的意思是 外部化所有字符串,包括错误消息。 不使用包含文本的图像。 设计UI时要考虑文本扩展。 使用伪翻译来测试用户界面的早期阶段。 等等 在您从事的项目中,这些项目是否属于“不错”类别,并让本地化团队担心其余的工作,还是在开发过程中内置了本地化准备?我很想听听开发人员如何看待本地化。

2
使用gettext翻译更长的文本(视图和电子邮件模板)
我正在开发一个多语言的PHP Web应用程序,并且有很长的文本需要用gettext进行翻译。这些是电子邮件模板(通常很短,但仍然是几行)和视图模板的一部分(较长的描述性文本块)。这些文本将包括一些简单的HTML(强调的内容如粗体/斜体,可能是此处或此处的链接)。模板是捕获其输出的PHP脚本。 问题在于,gettext对于处理较长的文本似乎非常笨拙。长文本通常会比短文本具有更多的变化-我可以更改msgid并确保在所有翻译中都进行更新(msgid较长时可能需要大量工作,并且容易出错),或者我可以保留msgid保持不变,仅修改翻译(这会在模板中留下误导的过时文本)。另外,我也看到了反对在gettext字符串中包含HTML的建议,但要避免将单个自然文本分成很多块,这将是翻译和重组的更大噩梦,并且我也看到了反对的建议将gettext字符串不必要地拆分为单独的msgids。 我看到的另一种方法是完全忽略这些较长文本的gettext,并为每个语言环境在外部子模板中分离这些块,而只为当前语言环境包括一个。缺点是我将gettext .po文件和位于完全不同位置的单独模板之间的翻译工作分开了。 由于此应用程序将来会被用作其他应用程序的起点,因此我正试图提出长期最佳的方法。在这种情况下,我需要一些最佳实践建议。您如何实施类似案例?哪些结果可行,什么却是坏主意?

2
API应该使用en_US还是en_GB或两者都使用?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我应该用美式拼写还是英式拼写编写API?还是我应该将它们都映射到一个并在内部使用我喜欢的任何人来使它们都能工作?目前,大多数API都使用美国拼写。有什么解决方案? 编辑:有没有一种方法可以对此进行标准化。可能两者都支持?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.