Блог

В настоящее время я переношу веб-приложение с подхода интернационализации на основе базы данных (каждое слово имеет запись в таблице перевода и фактический перевод) на веб-приложение на основе Zend_Translate и CSV-файлов.

Мне нужно предоставить удобный для конечного пользователя способ быстрого и простого обновления этих переводов. В идеале, чтобы свести к минимуму риск взлома, пользователи не должны редактировать CSV-файлы напрямую, но им будет показана удобная форма с полями.

Знаете ли вы автономный интерфейс для перевода на основе PHP, совместимый с конечным пользователем, который поддерживает один из предлагаемых Zend_Translate адаптеров — в идеале gettext или csv?

Что-то вроде Rosetta от Python / Django, но на PHP? Rosetta делает именно то, что мне нужно:

но я бы очень хотел остаться с PHP здесь по причинам настройки сервера.

SimplePO выглядит так, будто движется в правильном направлении, но слишком прост — похоже, он не способен обрабатывать несколько языков, каталогов и множественное число.

Я не видел другого и, вероятно, по следующей причине. Несмотря на то, что написано на веб-сайте SimplePO, переводчикам не нравятся системы параллельного перевода, как показано выше, и часто они не будут работать с ними.

Именно так программисты представляют себе работу переводчиков, и это неверно. Переводчики работают с инструментарием под названием TMX, Translation Memory Exchange (общее название смотрите в Okapi — реализация с открытым исходным кодом, чтобы получить представление об этом), и в нем они создают словари перевода для слов, фраз и предложений. Они берут файл различных форматов и загружают его в программное обеспечение TMX, это дает им первый проход, который переведен на 60%, 70% и т.д., Но, как и Google language API, Ужасно искажен с точки зрения смысла на целевом языке.

Затем, что они делают, это переводят слова, не обрабатываемые TMX, добавляя в словари там, где это логично, и они переводят это в разговорный язык, то есть заставляют его работать на целевом языке и придают ему смысл. По этой причине переводчик всегда должен переводить на свой родной язык.

Они делают это таким образом по ряду причин: а) это имеет смысл, работает и снижает их рабочую нагрузку и б) потому что им платят за word, а параллельный перевод не позволяет им использовать свои инструменты и максимизировать свой доход.

Переводчикам нужен файл в формате, который вы можете экспортировать, они могут импортировать и переводить, экспортировать и отправлять вам обратно для импорта.

Форматы файлов могут быть csv, rtf, tmx, xliff, gettext, и если вы прочитаете документы Symfony framework, вы сможете увидеть, как они это делают и обрабатывают (на мой взгляд, они неплохо справляются).

Сказав все это, я был в похожем положении около 8 лет назад, когда мне нужно было написать сайт на английском, французском, немецком, венгерском и словацком языках, и я сделал то же самое, что и SimplPO, и просто написал свое собственное параллельное приложение, позволяющее это сделать. Однако компания, для которой мы писали приложение, выполнила весь свой собственный перевод собственными силами, поэтому мы не столкнулись с проблемой с переводчиками. Когда мы это делали, мы написали экспорт в RTF и импорт из RTF (что само по себе ошеломляет), чтобы переводчики могли функционировать, как описано выше.

Однако SimplePO — единственная другая реализация идеи, которую я видел. Такие фреймворки, как Zend, похоже, думают, что вы просто создаете теги поиска для замены слов и фраз и не встраиваете в приложение никакого элемента управления для управления процессом. Следовательно, вскоре он выходит из-под контроля, и его обслуживание становится сложным и дорогостоящим.

Большинство людей, которые пишут многоязычные веб-сайты, на самом деле этого не делают. Они пишут мастер-сайт, а затем делают копию, переводят ее и поддерживают переведенную версию. Нам логические типы кажутся неуклюжими, но на самом деле они очень эффективны.

Одна из причин, по которой это эффективно, заключается в том, что i18n и l10n касаются многих других вещей, помимо языка.

• Внешний вид и ощущения. Англосаксы любят холодные цвета и шрифты San serif, испаноязычные народы любят шрифты с засечками и более яркие цвета. И когда вы знакомитесь с другими культурами, ожидания сильно различаются по планировке, типам, цветам и т.д.

• Французский и в некоторой степени немецкий языки на 30% длиннее и более подробны, чем эквивалентный английский, поэтому ваш макет очень быстро отправляется в корзину для рук.

• Семитский язык справа налево

• Японский и другие языки, не основанные на алфавите, могут запускать ltr rtl сверху вниз, а в некоторых даже нет пробелов
• даты? США, Япония, Великобритания, венгерский как все разные
• форматы валют и чисел, даже не начинайте меня

Что ж, извините, что продолжаю и подводлю итог: — Для простого перехода из стороны в сторону просто напишите это сами, у меня ушло около двух недель без каких-либо фреймворков, и я работал над этим по ходу дела, просто используя замену тегов. Но сделайте еще немного и обдумайте, что вы делаете. Внимательно.

Если вы можете использовать файлы gettext (Zend_Translate поддерживает их), вы можете попробовать POEdit. Он довольно прост в использовании и поддерживает формы множественного числа начиная с версии 1.3.

Однако пользователям придется загружать файлы и повторно загружать их в конце, потому что POEdit не является онлайн-инструментом. Я не знаю ни одного другого веб-инструмента.

Вы можете попробовать Transtable, простой веб-интерфейс для редактирования переводов в массивах php.