巴西葡萄牙语网站支持俄语、普通话和日语
我们有一个巴西葡萄牙语网站，使用 Coldfusion（用于用户界面）、Hibernate（用于业务逻辑）和 Oracle 数据库开发。
如果我们考虑支持俄语、普通话和日语，我们必须担心什么？
提前致谢。
We have a website in brazilian portuguese developed using Coldfusion (for the user interface), Hibernate (for the business logic) and Oracle database.
If we consider to support russian, mandarin and japanese languages what concerns do we must have?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
主要考虑因素是确保所有内容（我的意思是所有操作系统、shell、Web 服务器、应用程序服务器、数据库、编辑器）都配置为默认使用 utf-8 或 unicode。
如果您预计有很多亚洲用户，那么使用完整的 unicode 会稍微好一些，因为大多数中文字符适合 16 位 UTF-16，但是，在 utf-8 中可能会占用 24 或 32 位。
对于 Coldfusion 和 Oracle，这应该不会造成任何大问题。
另一个主要考虑因素是您计划如何处理国际化问题。
标准方法是将语言/文化特定项目保留在“捆绑包”中。有几种工具可以支持这一点，基本上，您用葡萄牙语编写应用程序，确保用户将看到的所有文本都在带引号的文字中，然后通过实用程序运行应用程序，该实用程序用库调用替换所有文字并将所有字符串提取到一个“捆绑”文件。然后，您可以编辑该捆绑包以添加其他语言版本的字符串。这样做的最大优点是这些格式是标准的，翻译机构将拥有编辑这些文件的工具 - 因此您可以轻松地将翻译外包给专家。
另一个需要更多工作但恕我直言会产生更好结果的选项是为支持的每种语言/文化分支前端版本。这解决了文本高度和字符串大小的许多问题。它还可以更好地处理文化规范——不同的文化对于地址和头衔等内容有不同的顺序和惯例。
小差异导致大问题的一个典型例子是爱尔兰共和国和邮政编码，他们只是没有它们。因此，如果您的表单验证坚持使用邮政编码，则会惹恼您的爱尔兰用户。英国确实有邮政编码，但它们是两个由空格分隔的 1 到 4 个字符的字母数字字符串，而不是更常见的 5 或 7 位数字代码。
The main consideration is to make sure everything (and I mean everything OS,shell,web server, appserver, database, editors) is configured to use utf-8 or unicode by default.
If you expect a lot of asian users its slightly better to use full unicode as most chinese characters fit into a 16 bit UTF-16, but, can take up 24 or 32 bits in utf-8.
With Coldfusion and Oracle this should not present any mojor problems.
The other main consideration is how you plan to handle the internationalisation isssues.
The standard way is to keep langauge/cultural specific items in a "bundle". There are several tools out there to support this, basically you write your app in portuguese making sure all text the user will see is in quoted literals, then run the app through a utility which replaces all literals with a library call and extracts all strings into a "bundle" file. You can then edit the bundle to add other language versions of the strings. The great advantage of this is that these formats are standard and translation agencies will have the tools to edit these files -- so you can easily outsource the translation to specialists.
The other option which requires much more work but IMHO produces a nicer result is to branch of a version of the front end for each language/culture supported. This gets around a lot of problems with text height and string size. Also it handles cultural norms better -- different cultures have differnet ordering and conventions for things like address and title.
A classic example of small differences causing big problems is the Irish Republic and Post Codes, they just dont have them. So if your form validation insists on a Zip code it will annoy your Irish users. The Brits do have post codes but these are two 1 to 4 character alphanumeric strings separated by a space, not the more usual 5 or 7 digit numeric codes.