使用 zend 框架的多语言内容管理网站 (CMS)
虽然我找到了很多与这个问题相关的资源，但没有一个能够准确地给出使用 Zend Framework 的多语言 CMS 的答案。
zend 框架中有许多可用的 z最终翻译适配器。但是数据库（mysql）驱动的网站最需要的一个（zend sql适配器）尚未发布。
对于那些非数据库驱动的多语言网站，内容可以放置在文件（xml、mo 或任何其他文件）中，并使用 zend 翻译适配器之一来处理内容以显示正确的语言。
我们将如何处理数据库驱动的多语言网站？以前我们习惯使用 php 和精心设计的多语言数据库，将每篇文章（页面）与每个所需的翻译保存在表格中。如果我们使用 zend 框架做同样的事情，那会是过度杀伤还是网站速度变慢？我们仍然使用 zend 缓存来提高速度，但我们将无法利用 zend 翻译的优势。稍后，当用于 sql 的 zend trans 适配器可用时，使用 zend trans 切换多语言内容管理系统是否会很容易。
有人试过这个吗？优点和缺点是什么？
另一个解决方案是保留我们精心设计的多语言数据库，并在管理区域中使用 GUI 进行每次更改时生成基于 xml 的语言文件。然后使用 zend 翻译适配器之一来处理这些 xml 文件。我想这可能有点矫枉过正，用大炮杀死一只鸟:)
当我谈论将整个页面的内容放入数据库时。它可以包含一些 html 标签，例如 b、span、br、p 等。zend 翻译如何处理其中包含 html 标签的内容？
如果有人之前已经实现过这个，那么使用 zend 框架处理多语言内容管理网站的最佳方法是什么。
有专家意见吗！
Although I find quite a lot resources related to this question but none of them is precisely giving the answer to a Multilingual CMS using Zend Framework.
There are many zend translate adapters available in zend framwork. But the one (zend sql adapter), which is most need for database(mysql) driven websites, is not yet released.
For those multilingual websites, which are not database driven, contents can be placed in files (xml, mo, or any other) and one of the zend translate adapter is used to process the contents to display the correct language.
How we will deal with database driven multilingual website? Previously we were habit of using php with well-designed multilingual database keeping each article (page) in table with every required translation. If we will do the same by using zend framework, would that be over kill or slow website? We still make use of zend cache to make it faster, but we won't able to take the advantage of zend translate. Later, when the zend translate adapter for sql will be available, would that be easy to switch that multi-lingual content managed system by using zend translate.
Has anyone tried this? What could be the pros and corns?
Another solution could be keeping our well design multilingual database and generate xml based language files on every change admin make using GUI in admin area. And then use one of zend translate adapter to handle these xml files. I guess that could be overkill, killing a bird with cannon :)
When I am talking about placing the whole page's content in database. It can include some html tags such as b, span, br, p etc. How well the zend translate can deal contents with html tags in it?
If someone already has implemented this before, what could be the best way to deal with Multi-lingual content managed website using zend framework.
Any expert opinion!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这些都是错误的假设。并不是说数据库驱动的应用程序需要使用数据库驱动的翻译系统。您可以轻松使用静态文件系统。
我认为您有点错误 - 我知道您想使用翻译来翻译页面（文章）的动态内容。 Translate 的设计目的是使视图（静态内容）国际化。我的意思是诸如登录或注册或欢迎文本等。这些确实应该在文件中（将文件视为静态缓存）而不是比在数据库中，因为它会产生巨大的负载（无论如何数据库都应该被缓存）。存储在DB中的文章是另一回事，你想要实现的是多语言页面内容。您可以在没有翻译的情况下轻松处理该问题（请记住，翻译对视图有好处！），只需向表中添加国家/语言标志并通过模型检索合适的（针对给定语言过滤的）数据。它非常简单，不需要任何后端进行翻译。
我不确定 Translate 是如何工作的，但我可以假设它会检查语言，然后加载整个翻译文件并将其作为集合（或简单的关联数组）存储在脚本内存中，只是为了提供快速而强大的翻译机制（注意，它不需要为每个给定的键调用数据库或文件，因为它们都在内存中）。以这种方式保留整个页面、文章根本没有意义，主要是因为每页只需要 1-2 篇文章（那为什么要浪费内存？），有时还需要数百个本地化视图字符串（所以您不想为每个对象调用数据库或文件）
如果谈论静态内容的翻译 - 这确实是非常常见的解决方案：将翻译保留在数据库中以便于访问/更改并生成 XML/CSV/任何文件当变化发生时。
这可能会很好，但你仍然在考虑动态内容。静态内容应在视图内格式化。所以，我猜是死路一条。
底线：使用翻译来完成您提到的所有内容，这就像用大炮杀死一只鸟:)
These are wrong assumptions. It is not said, that DB driven application needs to use DB driven translate system. You can easily use static-files system.
I think that you are a little bit mistaken - I understand that you would like to use Translate for the dynamic content of your page (articles). Translate is rather designed to internationalize the views - the static content. I mean things like login or register or welcome text, etc. And these really should be in the files (consider files a static cache) rather than in the DB, because of huge load it would make (DB should be cached anyway). The articles stored in the DB is a different thing, and what you want to achieve is multilangual page content. You can handle that easily without Translate (remember, Translate is good for views!), simply add a country/language flag to your tables and retrieve suitable (filtered for given language) data through your model. It is really straightforward and it doesn't need any backend for translation.
I am not sure how Translate works, but I can assume that it checks the language and then loads whole translation file and stores it in script memory as a collection (or simple associative array) just to provide quick and robust translation mechanism (notice, that it wouldn't need to call a DB or a file for every given key, because all of them would be in the memory). Keeping the whole pages, articles this way wouldn't make sense at all, mainly because you need only 1-2 articles per page (why waste memory then?) and sometimes a hundreds of localized view strings (so you don't want to make a call to a DB or file for each of them)
If talking about translations for a static content - it really is very common solution: keeping the translations in the DB for easy access/change and generating the XML/CSV/whatever files when change occurs.
It would probably deal good, but still, you are thinking about dynamic content. Static content should be formatted inside the view. So, dead end I guess.
Bottom line: Using Translate for all of that you mentioned, it would be killing a bird with a cannon :)