В Zend Framwork доступно множество адаптеров Zend Translate. Но тот (адаптер Zend SQL), который больше всего нужен для сайтов, управляемых базой данных (mysql), еще не выпущен.
Для тех многоязычных веб-сайтов, которые не управляются базой данных, содержимое может быть помещено в файлы (xml, mo или любые другие), и один из адаптеров zend translate используется для обработки содержимого для отображения правильного языка.
Это неправильные предположения. Не сказано, что управляемое БД приложение должно использовать управляемую БД систему перевода. Вы можете легко использовать систему static-files.
Как мы будем работать с многоязычным веб-сайтом, управляемым базой данных? Ранее мы привыкли использовать php с хорошо разработанной многоязычной базой данных, сохраняя каждую статью (страницу) в таблице с каждым необходимым переводом.
Я думаю, что вы немного ошибаетесь - я понимаю, что вы хотели бы использовать Translate для динамического содержимого вашей страницы (статей). Translate скорее предназначен для интернационализации представлений - статического контента. Я имею в виду такие вещи, как логин или регистр или текст приветствия и т. Д. И они действительно должны быть в файлах (рассматривайте файлы как статический кеш), а не в БД из-за огромной нагрузки (БД должна быть кэширована в любом случае). Статьи, хранящиеся в БД, - это совсем другое, и вы хотите достичь многоязычного содержания страницы. Вы можете легко справиться с этим без Translate (помните, что Translate хорош для представлений!), Просто добавьте флаг страны / языка в ваши таблицы и извлеките подходящие (отфильтрованные для данного языка) данные через вашу модель. Это действительно просто и не нуждается в каком-либо бэкенде для перевода.
Я не уверен, как работает Translate, но я могу предположить, что он проверяет язык, а затем загружает весь файл перевода и сохраняет его в памяти скриптов в виде коллекции (или простого ассоциативного массива) просто для обеспечения быстрого и надежного механизма перевода ( обратите внимание, что не нужно вызывать БД или файл для каждого данного ключа, потому что все они будут в памяти). Хранить целые страницы, статьи таким способом вообще не имеет смысла, в основном потому, что вам нужно всего 1-2 статьи на страницу (зачем тогда тратить память?), А иногда и сотни локализованных строк просмотра (так что вы не хотите сделать вызов БД или файла для каждого из них)
Другим решением может быть сохранение нашей хорошо спроектированной многоязычной базы данных и создание языковых файлов на основе xml при каждом изменении, которое вносит администратор, используя графический интерфейс в административной области. А затем используйте один из адаптеров Zend Translate для обработки этих XML-файлов. Я думаю, это может быть излишним, убить птицу пушкой:)
Если говорить о переводах для статического контента - это действительно очень распространенное решение: хранить переводы в БД для легкого доступа / изменения и генерировать XML / CSV / любые файлы при изменении.
Когда я говорю о размещении всего содержимого страницы в базе данных. Он может включать некоторые html-теги, такие как b, span, br, p и т. Д. Насколько хорошо Zend Translate может обрабатывать содержимое с html-тегами?
Вероятно, это будет хорошо, но все же вы думаете о динамическом контенте. Статическое содержимое должно быть отформатировано внутри представления. Итак, тупик, я думаю.
Итог: используя Translate для всего того, что вы упомянули, было бы убить птицу пушкой:)