多语言 PHP 应用程序:最佳实践?

发布于 2024-11-07 04:48:33 字数 424 浏览 1 评论 0原文

我想获得您对我在 PHP MVC Web 应用程序上实现多语言支持的方式的反馈。这就是我所做的:

  • 在 /app 文件夹中我创建了一个 /languages 文件夹,其中包含每种语言一个文件(english.php、spanish.php 等)
  • 每个文件包含一系列具有相同内容的变量每个文件中的名称,包含要在视图中呈现的文本
  • 然后这些变量会在不同的视图中回显
  • 当用户更改
  • 每个视图的控制器中的语言时,会更新“语言”cookie 变量,我包含以下语言文件格式:

包括 $_SERVER['DOCUMENT_ROOT'] 。 “/应用程序/语言/”。 $_COOKIE["语言"] 。 “.php”;

对我来说听起来很漂亮。您对这种方法有任何负面想法吗?

I'd like to get your feedback over the way I implemented multi-language support on my PHP MVC web app. That's how I did:

  • in the /app folder I created a /languages folder which contains one file per language (english.php, spanish.php, etc.)
  • each file contains a serie of variables with the same names in each files, containing the texts to render in the views
  • these variables are then echoed in the different views
  • a "language" cookie variable is updated when the user changes the language
  • in the controller of each view, I include a language file on the following format:

include $_SERVER['DOCUMENT_ROOT'] . "/app/languages/" . $_COOKIE["language"] . ".php";

Sounds pretty neat to me. Would you have any negative thoughts about this method?

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

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

发布评论

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

评论(4

盗心人 2024-11-14 04:48:34

只是一些想法

  • 如果您的每种语言都有一个文件,并且您的网站有多个页面,您很快就会忘记哪个标签在哪个页面上包含哪个文本,
  • 如何确保在创建新标签时所有标签中都有标签其他语言以及它们是否已翻译?
  • 您如何处理不同语言的格式?罗曼语语言往往比英语长 30% 左右,因此可能会破坏页面流程。
  • 同样,希伯来语是从右到左 (RTL),而不是像欧洲语言那样是 LTR?或者中文和日文的行流可能不同并且没有空格?
  • 你们如何进行翻译?导出文件并再次导入?您是否打算使用 xliff 或 TMX 或 gettext 的某个版本来使译者的工作更轻松并且翻译成本更便宜?
  • 你们如何对翻译进行质量检查?

just some thoughts

  • If you have one file per language and your site has more than a few pages you will quickly loose track of which tag holds which text on which page
  • How do you ensure that when you create a new tag that there are tags in all the other languages and that they are translated?
  • how do you handle formatting for different languages? Romance languages tend to be about 30% longer than English so can screw up the page flow.
  • In the same vein what about Hebrew which is right to left (RTL) not LTR as with european language? Or Chinese and Japanese with potentially different line flows and no white space?
  • How do you do the translations? Export the files and import them again? Do you intend to use xliff or a version of TMX or gettext to make the translators life easier and translation costs cheaper?
  • How do you QA the translations?
迟到的我 2024-11-14 04:48:34

由于您只有语言文件中的数据,因此我建议使用 GetText。它是 C++ 标准 GetText 的国际化端口,有大量工具可以构建语言文件,并且由于运行时编译文件而速度非常快。

您本质上是使用一种 INI 文件格式构建数据文件(例如 fr.poen.po),并将这些文件编译为专用的 .mo-文件(fr.moen.mo、...)并使用静态函数 _() 简单地回显国际化字符串,例如echo _("Hello World"); 会产生德语输出 Hallo Welt 或(如果 .mo 文件中没有可用的翻译)默认字符串 Hello World

至于选择正确的语言:这取决于您的要求。正如已经指出的,您应该使用浏览器的 Accept-language 标头,并且可能希望通过会话信息添加对覆盖的支持。

As you are just having data in the language files, I would recommend using GetText. It is a port of the standard GetText of C++ for internationalization, there are tons of tools to build up the language files and is very fast due to compiled files during runtime.

You essentially build up your data-files (e.g. fr.po, en.po) with a kind-of INI-file format and compile those files to specialized .mo-files (fr.mo, en.mo, ...) and simply echo the internationalized strings with the static function _(), e.g. echo _("Hello World"); would produce the german output Hallo Welt or (if no translation is available in the .mo-files) the default string Hello World.

As for choosing the right language: that depends on your requirements. As already pointed out, you should use the Accept-language-Header of the browser and might want to add support for an overwrite through session-information.

要走就滚别墨迹 2024-11-14 04:48:33

由于您使用的是 PHP 5.3.2,如果可以的话,我绝对建议您查看 intl 扩展。它充满了方便的函数和类来协助 i18n。例如,您可以使用以下代码片段从可用的语言中为访问者生成“最适合”的语言:

$langs = array('en', 'fr', 'de');
$preferences = Locale::acceptFromHttp($_SERVER['HTTP_ACCEPT_LANGUAGE']);
$locale = Locale::lookup($langs, $preferences);

除了直接逐字替换之外,还有很多需要考虑的事情。不同的语言有不同的格式约定。这篇 Zend 文章 中提供了大量可能有用的信息。

我的代码使用 XSL 进行模板化,所以就我个人而言,当涉及到翻译时,我使用 XML 语言文件和 XPath 查询,以便模板可以直接理解语言文件,但 PHP 也可以使用 MessageFormatter

老实说,我会避免使用数据库作为存储,只是为了性能。

As you're on PHP 5.3.2 I'd definitely recommend checking out the intl extension if you can. It's full of handy functions and classes to assist in i18n. For instance you can use the following snippet to generate a "best-fit" language for your visitor from those you have available:

$langs = array('en', 'fr', 'de');
$preferences = Locale::acceptFromHttp($_SERVER['HTTP_ACCEPT_LANGUAGE']);
$locale = Locale::lookup($langs, $preferences);

There's also a lot more to think about than straight word-for-word replacements. Different languages have different formatting conventions. There's a lot of information in this Zend article that might prove useful.

My code uses XSL for templating so personally, when it comes to translations I use XML language files and XPath queries so that the language file can be understood directly by templates but is also available to PHP for formatting strings with MessageFormatter.

I'd avoid using the database as a store to be honest, simply for performance.

泪冰清 2024-11-14 04:48:33

您还可以解析接受语言标头以帮助决定做什么。

Accept-Language:en-GB,en-US;q=0.8,en;q=0.6

我的看起来就是这样。这并不是万无一失的,但它可能是一种自动设置适当 cookie 的方法。

You could also parse the accept-language header to help decide what do do.

Accept-Language:en-GB,en-US;q=0.8,en;q=0.6

Mine looks like that. It's not fool proof, but it could be a way to set the appropriate cookie automatically.

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