创建多语言网站时我应该了解和考虑什么

发布于 2024-08-22 10:31:22 字数 37 浏览 5 评论 0原文

我正在创建一个至少有 5 种语言的多语言网站,我应该考虑什么

I'm Creating a Multi Language website with at least 5 language, what should I consider

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

天煞孤星 2024-08-29 10:31:22

在技​​术方面,您可以使用 Zend、Kohana 或 Rails 等框架,它们通常能够用标签替换内容,然后在运行时用选择的语言填充标签。不同的语言驻留在适当命名的目录中,并且可以由浏览器语言标签或其他机制触发。如果您没有使用具有此功能的框架,那么请研究一个框架以了解它是如何完成的。

之后,没有特定的顺序。

  • 为什么要多语言?你确实需要一个令人信服的理由来这样做,因为你所承担的工作量很大、很复杂、很繁重。我知道人们如何以及为何喜欢母语网站的所有原因,但对于多语言网站的资金投资,您需要获得适当的投资回报,而不仅仅是为了投资而投资。
  • 本地化(L10N 或国际化 i18n)不仅仅与语言有关。这是关于文化差异。盎格鲁撒克逊人喜欢冷静克制的无衬线字体网站。拉丁美洲和拉丁美洲文化喜欢更鲜艳的色彩和草书字体。等等。因此,您需要有一种机制来更改每种语言的 css(要真正有效)
  • 谁在进行翻译?请记住,这是您需要的惯用翻译,Google Translate API 不会删除它,并且您需要母语人士来翻译目标。例如,如果您使用英文原版中的无花果(法语意大利语等)。您需要英语到法语、英语到德语、英语到意大利语、英语到西班牙语的翻译(看到成本不断上涨了吗?)。一个好的机构会为您提供所有这些并管理整个流程。
  • 校对阅读。您能熟练掌握 5 种语言来检查上述工作是否正确吗?
  • 维护。再次假设英语是基本语言,并且有新页面或页面重写甚至拼写错误,您需要经历上述过程并更新站点,因此您需要一个良好的工作流程和过程控制系统来确保更改和更新有效地工作。持续的维护可能会耗费大量时间和成本,因此在开始之前先解决掉这个问题。
  • 请注意本地化程序/应用程序的人的建议这根本不是同一件事。
  • 许多解决方案实际上为每种本地化使用单独的网站,而不是一体化的方法。当我们想将所有内容放入一个“技术”包中时,这可能是违反直觉的。但是,您可以通过分离站点轻松应对不同的样式、字符集和 LTR 文本等。您可以错开更新并更有效地管理工作流程,添加新站点要简单得多,并且它允许您使用可能会出现的不同 URL。是必需的,并允许您优化每个网站的 SEO。

On a technical front not a lot, you can use a framework like Zend or Kohana or Rails etc. which usually have the ability to replace the content with tags and then fill the tag with the language of choice at run time. The different languages reside in appropriately named directories and can be triggered by the browser language tag or another mechanism. If you are not using a framework with this facility then study one to see how it is done.

After that and in no particular order.

  • Why multilingual? you really need a compelling reason to do it as the workload you are taking on is large and complex and onerous. I know all the reasons about how and why people like sites in their native language but for a multi lingual site's investment in money you need to be making a proper return on the investment and not just doing it for the sake of it.
  • Localising, L10N or internationalisation i18n, is not just about language. It is about about cultural differences. Anglo Saxons like cool restrained san-serif type sites. Latin and Latin American cultures like more vibrant colours and cursive type faces. And so on. So you need to have a mechanism that will change the css for each language as well (well to be truly effective you do)
  • Who is doing the translation? Remember it is an idiomatic translation you need, Google Translate API will not cut it and you need a native speaker to translate from and to the target. So for example if you are using FIGS (French Italian etc) from an English original. You need a translator for English to French, English to German, English to Italian, and English to Spanish (see the costs mounting?). A good bureau will provide all this for you and manage the process though.
  • Proof reading. Can you speak 5 languages well enough to check that above work is correct?
  • Maintenance. Again assuming English is the base language and there is a new page or a page rewrite or even a typo you need to go through the above process and update the site so you need a good workflow and process control system to ensure that the changes and updates work effectively. The ongoing maintenance can be crippling in time and cost, work it out before you start.
  • Beware of advice form people who localise programmes/applications It is not remotely the same thing.
  • Many solutions actually use separate web sites for each localisation rather than the all in one approach. This can be counter intuitive when we want to put it all into one "technical" package. However you can by separating the sites easily cope with different styles, and character sets and ltr text etc. You can stagger updates and manage the workflow more effectively, adding new site is far far simpler and it allow you to use the different URL's that may be required and allows you to optimize each site for SEO.
孤星 2024-08-29 10:31:22

当我开发双向 Web 应用程序时,我发现以下做法很有帮助:

使您的页面易于全球化
尽可能地遵循这些最好的
做法:

❑ 避免使用绝对定位和
控件的尺寸。

❑ 使用整个宽度和高度
表格。

❑ 相对于元素的大小
表单的整体大小。

❑ 对每个数据使用单独的表格单元格
控制。

❑ 避免启用 NoWrap 属性
在表格中。

❑ 避免指定 Align 属性
在表格中。

来源:MCTS 自定进度培训套件:Microsoft .NET Framework 2.0 基于 Web 的客户端开发< /a>.

  • 作为一般提示,我发现使用表格而不仅仅是 DIV 非常有帮助。

When I developed bi-directional web applications, I found the following practices helped too much:

To make your page as easy to globalize
as possible, follow these best
practices:

❑ Avoid using absolute positioning and
sizes for controls.

❑ Use the entire width and height of
forms.

❑ Size elements relative to the
overall size of the form.

❑ Use a separate table cell for each
control.

❑ Avoid enabling the NoWrap property
in tables.

❑ Avoid specifying the Align property
in tables.

source: MCTS Self-Paced Training kit: Microsoft .NET Framework 2.0 Web-based client development.

  • As a general tip, I found using tables instead of just DIVs is very helopful.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文