存储网站的多种语言版本的最佳方式是什么?

发布于 2024-09-09 04:42:59 字数 179 浏览 3 评论 0原文

我的网站(在 Linux 服务器上)需要支持多种语言。
拥有/存储同一网站的多种语言版本的最佳实践是什么?
我能想到的一些:

  1. 在数据库中存储
  2. 每种语言的不同视图文件
  3. gettex
  4. PHP 文件中的硬编码字(例如在 phpBB 中)

My web site (on Linux servers) needs to support multiple languages.
What is the best practice to have/store multiple languages versions of the same site?
Some I can think of:

  1. store in DB
  2. different view file for each language
  3. gettex
  4. hard coded words in PHP files (like in phpBB)

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

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

发布评论

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

评论(3

凉风有信 2024-09-16 04:42:59

对于网站,您实际上需要考虑几类内容进行本地化:

  1. 在许多情况下您会在 CMS 中创建、编辑和发布的文章类型内容元素。
  2. 每个页面(或页面子组)共有的较小内容块,例如标语、简介、联系表单周围的文本,但也导入了新闻摘要或广告和附属链接等内容。其中一些可能仅针对一种语言显示(例如,如果您不在某些地区提供某些服务,或者没有针对特定语言导入的适合语言的内容:删除一个元素可能比向不会说英语的人提供英语更好)。
  3. 纯粹的功能元素,例如“单击此处发表评论”、“更多...”、高级导航等,有时是模板的一部分。其中一些可能是内部图像。

对于 1. 主要决定是是否使用 CMS。如果是,您绝对需要选择一种支持多种语言的语言。我不太了解 PHP CMS 的最新发展,但几个 Django CMS 应用程序(Django-CMS-2、FeinCMS)支持多语言内容。例如,不要忘记日期戳也需要本地化(或者您可以通过选择 ISO 日期来解决这个问题,尽管这可能并不总是可行)。如果您不使用 CMS,并且所有内容都在 HTML 文件中,那么 gettext 是最佳选择,并将 .mo 文件(以及离线 .po 文件)按语言保存在文件夹中。

2.如果您的 CMS 具有良好的多语言支持,请在 CMS 中获得尽可能多的信息。原因是这些位确实会发生变化,并且您希望尽可能少地编辑模板。如果您自己编写代码,请考虑导出每种语言的所有 CMS 字符串的方法,以便将它们交给翻译人员。否则,再次gettext。主要问题是这些元素可能需要硬编码语言选择代码(if $language = X display content1 ...

对于 3.,如果它在您的模板中,请使用 gettext。对于图像,每种语言的文件夹会派上用场,并且看在上帝的份上,请选择可以自动生成的图像,否则您(或您的图形艺术家)会因为使用您所使用的语言的字符串编辑数百个自定义图像而发疯。不明白。

对于 2. 和 3.,从语言选择中抽象可能有助于选择适当的块或内容目录(其中保存本地化图像或 .mo 文件)。

您绝对要避免的是保留一堆包含大量文本内容的 HTML 文件,这对维护来说将是一场噩梦。

编辑:有关 gettext、.po 和 .mo 文件的所有内容都在 GNU gettext 手册中(比你想知道的还要多)或稍微过时但更友好的教程。对于 PHP,有 PHP gettext 函数,还有 Zend 语言环境文档

With web sites, you really have several categories of content to consider for localization:

  1. The article-type content elements that you would in many cases create, edit and publish in a CMS.
  2. The smaller content blocks that are common to every page (or a sub-group of pages), such as tagline, blurb, text around a contact form, but also imported content such as a news ticker or ads and affiliate links. Some of these may only appear for one language (for example, if you don't offer some services in some regions, or don't have, say, language-appropriate imported content for a particular language: it can be better to remove an element rather than offering English to people who may not speak it).
  3. The purely functional elements, like "Click here to comment", "More...", high-level navigation, etc., which are sometimes part of your template. Some of these may be inside images.

For 1. the main decision is using a CMS or not. If yes, you absolutely need to choose one that supports multiple languages. I'm not up-to-date with recent developments in PHP CMS's, but several of the Django CMS apps (Django-CMS-2, FeinCMS) support multi-language content. Don't forget that date stamps, for example, need to be localized, too (or you can get around this by choosing ISO dates, though that may not always be possible). If you don't use a CMS, and everything is in your HTML files, then gettext is the way to go, and keep the .mo files (and your offline .po files) in folders by language.

For 2. if you have a CMS with good multi-lingual support, get as much as possible inside the CMS. The reason is that these bits do change, and you want to edit your template as little as possible. If you write code yourself, think of ways of exporting all in-CMS strings per language, to hand them to translators. Otherwise, again, gettext. The main issue is that these elements may require hard-coding language-selection code (if $language = X display content1 ...)

For 3., if it's in your template, use gettext. For images, the per-language folders will come in handy, and for heaven's sake make choose images the generation of which can be automated, or you (or your graphic artist) will go mad with editing 100s of custom images with strings in languages you don't understand.

For both 2. and 3., abstracting from the language selection may help selecting the appropriate blocks or content directory (where localized images or .mo files are kept).

What you definitely want to avoid is keeping a pile of HTML files with extensive text content in them that would be a nightmare to maintain.

EDIT: Everything about gettext, .po and .mo files is in the GNU gettext manual (more than you ever wanted to know) or a slightly dated but friendlier tutorial. For PHP, there's are the PHP gettext functions, and also the Zend Locale documentation

蝶…霜飞 2024-09-16 04:42:59

我建议使用 Zend_Translate 的 Gettext 适配器来解析 mo 文件。非常高效+缓存。您的调用将类似于

echo $translation->_("Hello World");

Which 会找到该指定字符串的区域设置特定键。

I recommend using Zend_Translate's Gettext adapter which parses mo files. Very efficient + caching. Your calls would be like

echo $translation->_("Hello World");

Which would find the locale specific key for that specified string.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文