使用多种语言文件还是 1 个更好？
根据您的经验，在使用 gettext 扩展的 PHP 项目中，对每种语言使用 1 个语言文件还是多个较小的语言文件更好？我什至不确定是否可以使用多个文件，因为服务器缓存了语言文件，所以我很难测试。
我在一个社交网站上做多种语言，到目前为止，只有注册页面，大约是 200 个页面中的 1 个，它有 35 个文本字符串需要翻译，按照这个速度，每种语言的语言文件会非常大，所以我在想也许为不同的页面或论坛部分和博客部分等部分制作不同的语言文件会更好，但如果没有什么区别，那么我宁愿不浪费时间为每种语言制作多个较小的文件。
我意识到每种情况都是不同的，唯一真正的答案是测试它，但我希望这次避免这种情况，只是得到更有经验的人的一些意见，这是我第一次使用 gettext，谢谢
From your experience, is it better to use 1 language file or multiple smaller langauge files for each language in a PHP project using the gettext extension? I am not even sure if it is possible to use multiple files, it is hard for me to test since the server caches the language files.
I am doing multiple languages on a social network site, so far just the signup page which is about 1 out of 200 pages to go and it has 35 text strings to translate, at this pace the language file for each language wold be really large so I was thinking maybe it would be better to do different language files for differnt pages or perhaps sections like forums section and blogs section but if it makes no difference then I would ratther not waste my time in making multiple smaller files for each language.
I realize every situation is different and the only real answer is to test it but I am hoping to avoid that this time and just get some oppinions of people more experienced, this is my first time using gettext, thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我会基于语言文件模块。使用 gettext 您需要为每种语言指定区域设置。最好为站点的每个模块或主要部分拥有单独的 .po/.mo 文件。
这是我的意见。 :-)
I would have the language files module based. With gettext you need to specify locale for each language. It would fit best to have a separate .po/.mo files for each module or big parts of your site.
That's my opinion. :-)
我通常会通过使用数据库来编辑站点（使用简单的数据库查找）来自动化该过程，并在多个文件中拥有多种语言。这让我可以聘请翻译人员来轻松验证当前的翻译。部署到生产环境只是将数据库转换为一组语言文件。
I typically automate the process and have multiple languages in multiple files by using a database to edit the site (using a simple db lookup). This lets me hire translators to come in and verify the current translation easily. Deploying to production then is simply turning the database into a set of language files.
根据经验，我会在每个文件的基础上分解语言，因为管理开销变得很重，并且存在很大的重复和错误范围。
另一个优点是，通过使用目录结构和命名约定，可以比大文件更容易地以编程方式选择正确的语言，并且更容易在项目的后期阶段编写管理工具。
其他人使用的一些格式也值得一看。许多框架都使用这种结构，例如 Dashcode、Symfony、Zend 等。还有一种 xml 格式 xliff，它是为处理翻译而构建的，并与翻译人员使用的许多工具集成。
From experience i would break the languages down on a per file basis as the management overhead becomes heavy and there is great scope for duplication and mistakes.
The other advantage it that by using a directory structure and naming convention the correct language can be selected programatically more easily than the large file and it is easier to write management tools at a later stage in the project.
It is also worth looking at some of the formats other people use. Many of the Frameworks use this sort of structure, Dashcode, Symfony, Zend etc. And there is an xml format xliff which is built to handle translation and integrates with many of the tools that translators use.
多个文件是最好的方法，但事情可能会变得混乱。
我们刚刚推出了一项名为 String 的免费新服务，它解决了管理多语言文件的大部分问题 - 就像本地化的大本营。您可以导入现有文件，也可以使用系统中的键和字符串从头开始。准备好后，您可以再次导出文件以运行您的应用程序。它适用于 PHP（数组）、PHP（定义）、po、yaml、ini 和 .strings 格式。
String 使您可以轻松地与翻译人员协作 - 您只需邀请他们加入项目并设置他们的语言权限。如果翻译人员需要更多信息，可以在每个字符串上留下评论和问题 - 如果情况不太正确，您可以使用历史功能恢复字符串。
无论如何，足够的推销！
请访问 http://mygengo.com/string 查看 - 我们很乐意提供您的反馈。
Multiple files are the best way to go, but things can get disorganized.
We've just launched a free new service called String which solves most of the problems of managing multiple language files - like a basecamp for localization. You can either import existing files, or start from scratch with keys and strings in the system. When you're ready, you can export the files again to run your app. It works with PHP (array), PHP (define), po, yaml, ini and .strings formats.
String allows you to collaborate with translators easily - you just invite them to a project and set their language permissions. Translators can leave comments and questions on each string if they need more info - and you can revert strings back using the History function if things aren't quite right.
Anyway enough sales pitch!
Check it out at http://mygengo.com/string - we'd love your feedback.