|
Навигация
|
Главная » Xml Как добавить интернациональную поддержку в ваши PHP-приложения (исходники)Источник: IBM developerWorks Россия Роберт Брэдли Оценка приложенияТребования к локализации могут быть довольно туманными, например "подготовить это приложение для Германии". Но даже когда кажется, что требования подробны, вы можете обнаружить вещи, которые менеджер по продукту упустил из виду.Возьмём, к примеру, приложение Yahoo! RSS news reader, показанное в Листинге 1. Когда страница вызывается в первый раз, отображается список заголовков по умолчанию, а также поле формы, в которое можно впечатать выбранную категорию новостей перед повторной отправкой страницы. Приложение проверяет введённую категорию и либо выводит сообщение об ошибке, если категория введена неправильно, либо отображает заголовки запрошенной категории. Листинг 1. RSS news от Yahoo!
Даже в таком простом виде, это приложение иллюстрирует многие проблемы, возникающие в ходе локализации. Оно также отражает некоторые преимущества и недостатки любого скриптового языка. Всегда можно сделать продукт быстро, но за это придётся заплатить свою цену. Пользовательский интерфейс (UI), бизнес-логика и конфигурация, или же их отсутствие, смешиваются вместе, безо всякой мысли о поддержке или расширении страницы новыми функциям. При локализации этой страницы для немецкого, и, возможно, других языков, становятся очевидными несколько препятствий:
Терминология по локализацииЕсли в ходе проекта вам придётся иметь дело с переводчиками, хорошо бы убедиться, что вы понимаете некоторые термины, которые вы, вероятно, встретите, общаясь с ними. В Таблице 1 даны определения нескольких общеупотребительных терминов, используемых лингвистами и специалистами по переводу.Таблица 1. Терминология по локализации
Встраивание локализацииЛистинг 2 показывает, как выглядит приложение RSS после рефакторинга и модернизации для поддержки локализации. Функциональная логика и среда локализации абстрагируются в класс обработчика (handler class). Всё, что остаётся в основном коде - это конструирование объекта обработчика страниц, шаблон HTML и обращения к методамaccessor обработчика для наполнения динамических фрагментов шаблона HTML.Листинг 2. Локализация RSS news
Преимущество рефакторинга состоит в том, что, возможно, программистам легче осуществлять поддержку кода. При этом вызывает сомнение, что пользовательский интерфейс стало легче поддерживать при отсутствии лингвистического контекста и встраивании значительных фрагментов HTML в PHP-код. Доверят ли PHP-программисты выполнять подобные изменения Web-разработчику? Какую цену придётся платить за то, что разработчикам внутреннего интерфейса приходится иметь дело с второстепенными запросами на изменение в пользовательском интерфейсе? Позднее я покажу вам, каким образом язык Extensible Stylesheet Language Transformation (XSLT) может помочь в разграничении уровней приложения. КонструкторНачнём с конструктора для класса обработчика (см. Листинг 3), чтобы увидеть, каким образом страница была изменена для локализации. При создании экземпляра обработчика страницы конструктор определяет соответствующую локаль, извлекает параметры конфигурации для этой локали, проверяет ввод пользователя, вычисляет весь некогда статический контент, руководствуясь текущей локалью пользователя, а затем проверяет любой пользовательский ввод. (Исходный код см. в разделе Downloads.)Листинг 3. RSSHandler.php
В данном примере ради простоты локаль жёстко закодирована на de_DE . В реальной жизни вам потребуется настраивать локаль в зависимости от бизнес-требований. Два общепринятых способа определения правильной локали - посмотреть URL запроса (например, www.ebay.de, amazon.fr), или же просто спросить пользователя и установить в его браузере cookie-файл с предпочтениями.Извлечение параметров конфигурацииПосле определения локали обработчик извлекает параметры конфигурации для Германии. В данном примере конфигурация предполагает использование пакета PEAR (Config.php), конфигурационный XML-файл (RSSConfig.xml), надстройку, относящуюся к области приложения (RSSConfig.php) и простой класс decorator для добавления HTML-разметки для некоторых параметров конфигурации (Configdecorator.php).Конфигурационный файл, показанный в Листинге 4, хранит информацию в XML-формате. Он определяет окружение извлечения строки ( //conf/textdomain ) - местонахождение зависимых от локали компонентов и имя файла сообщений.Примечание: Если вы загрузили и пробовали запустить примеры, обязательно измените путь к извлечённым и переведённым строкам, чтобы он соответствовал вашей среде. Конфигурационные файлы также сообщают приложению, как сконструировать правильный URL новостного канала Yahoo! ( //conf/de_DE/baseurl ), как проверить выбор пользователем типа новостного канала (//conf/de_DE/newtypes ) и какой тип новостей должен использоваться по умолчанию, если пользователь не сделал выбора.Листинг 4. Configuration.xml
Конфигурацию можно сделать более устойчивой к сбоям, добавив локаль "по умолчанию". В этом случае, если приложение пытается выполнить недопустимую локаль, всегда можно гарантировать какое-то разумное поведение приложения. Также можно расширить конфигурацию для задействования других возможностей приложения, например кобрендинга или ограничений на основе прав пользователей. Остальная часть объекта обработчика отвечает в основном за порождение текстовых фрагментов страницы соответствующим образом для каждой локали и обеспечение публичных методов accessor , которые делают эти кусочки переведённого текста доступными HTML-шаблону.Среда извлечения gettextПриложение использует среду извлечения строк с открытым исходным кодом под названиемgettext для фактуализации переведённых строк. Эта среда имеет несколько преимуществ:
gettext :
gettext() служит очевидной цели извлечения локализованного текста во время выполнения. Но также важно и то, что она является ещё и маркером для извлечения текста. Утилита xgettext ищет строки, которые отмечает эта функция.Все программные компоненты примера приложения, в том числе структура каталогов, определённая в конфигурации приложения, приведены в Листинге 5. Для каждой реализации gettext требуется аналогичная структура каталогов. Не требуется создавать дерево каталогов или базу данных сообщений для локали по умолчанию; строки для этой локали уже внедрены в код. Однако вам потребуется отредактировать файл RSSConfig.xml, точно указав полный путь к этим файлам для среды gettext .Листинг 5. Структура каталогов
Перевод файла сообщенийВ немецком файле сообщений жирным шрифтом отмечены те части, которые должен предоставить переводчик. Другими словами, переводчик должен заполнить пустые поля. Когда переводчик в первый раз открывает файл сообщений, эти части будут пустыми, а переводчик должен указать кодировку, которую он или она будет использовать, в данном случае, Latin-1, а также сделать переводы. ID сообщения (msgid ) - это оригинальный текст, отмеченный для извлечения с помощью вызова функции gettext() . Строка сообщения (msgstr ) - это та строка, которая должна быть в языке, на который делается перевод. В Листинге 6 показан перевод сообщения об ошибке, которое выдаётся, когда пользователь указывает неправильный тип новостей.Листинг 6. Немецкий файл сообщений, messages.po.de
При каком-либо изменении текста любой извлечённой строки, во время следующего создания файла сообщений будет создаваться и новое ID сообщения. Всякий раз, когда добавляются или изменяются строки, файл сообщений следует генерировать заново, иначе в целевых локалях новый текст будет отображаться непереведённым. В производственной среде все эти задачи (помимо подготовки исходного кода) обычно выполняет группа L10N. Но это не означает, что вы можете совершенно не уделять внимание лингвистическим проблемам. При локализации предложения не забывайте о следующих моментах:
При добавлении нового текста или изменении существующего, группа по локализации может применять другие утилиты gettext для слияния новых или изменённых строк с существующими файлами сообщений, что снимает необходимость повторного перевода.Проектирование локализацииОписанный выше подход к локализации вполне пригоден во многих случаях. Но с увеличением масштаба, имеет смысл подумать о проектировании приложений с помощью конструктивных шаблонов. Один из наиболее широко используемых шаблонов - Модель-Представление-Контроллер (MVC). Этот шаблон предлагает рассматривать приложение как совокупность различных уровней - презентации, управляющей логики и доступа к данным. Ещё одно преимущество MVC состоит в том, что с его помощью легче расширять контроллер и представление для обработки других типов HTTP-запросов либо как SOAP-сервисов, либо как XML API.Шаблон RSS MVCStruts, Ruby on Rails и Zend Framework основаны на такой многоуровневой философии проектирования. Если вы находите подход MVC привлекательным, изучите Zend Framework for PHP. Однако, чтобы уменьшить количество дополнительных пакетов, необходимых для примера приложения, я использую свой собственный MVC-шаблон, показанный в Листинге 7.Размер основного кода стал теперь ещё меньше. Он работает как контроллер, занимаясь по большей части обслуживанием HTTP-запросов. Он конструирует объект домена, задействующий бизнес-правила, которые мы уже обсуждали, извлекает модель данных сессии из домена, а затем передаёт модель классу представления для её трансформации в HTML, который отправляется обратно клиенту. Листинг 7. Контроллер RSS news, news3.php
Та же используемая ранее схема конфигурации приложения по-прежнему управляет поведением бизнес-правил. Изменился способ обработки пользовательского интерфейса нового уровня презентации. Этот уровень больше не использует поддержку HTML-шаблонов PHP. Вместо этого он полагается на XSL-трансформации. Модель домена - это рекурсивная структура данных вложенных объектов, которые можно реализовать как XML. Представление заставляет шаблон XSL трансформировать XML-представление данных сессии в локализованный HTML, возвращаемый браузеру клиента. Уровень презентацииXML-модель и XSL-шаблон, формирующие ядро уровня презентации показаны в Листинге 8. Модель содержит информацию о конфигурации, например типы новостей, в особенности то, как они могут отображаться для пользователя (//rss/newstypes/displaytypes ). Модель также возвращает выбор пользователем типа новостей (//rss/userinput/newstype ), а также доставленные заголовки новостей и URL (//rss/headlinelist/headline ). Если пользовательский выбор типа новостей был недопустимым, вместо заголовков модель возвратит код ошибки. Шаблон XSL получает доступ к фрагментам возвращённой модели данных для конструирования HTML, который отображается в браузере клиента.Листинг 8. Образец модели XML и шаблона XSL (RSSView.xsl) При таком подходе локализованные строки не извлекаются инструментом типа gettext . Вместо этого, каждая локаль имеет собственный XSL-шаблон. Поскольку теперь имеется понятный языковой контекст, распределять рабочую нагрузку при поддержке приложения должно быть легче. Web-разработчики, группа по локализации и даже менеджеры по продуктам могут взять на себя ответственность за реализацию самых незначительных связанных с пользовательским интерфейсом исправлений ошибок и запросов на создание функции.Для конструирования HTML класс представления использует поддержку XSL, идущую с PHP V5, модель данных и шаблон XSL. PHP V4 делает это по-другому. Данный подход также демонстрируется для тех ситуаций, когда необходимо локализовать старое приложение. В большинстве случаев XSLT включено по умолчанию, однако может потребоваться включить обработку XSLT в вашей установке PHP, чтобы всё это заработало. В Листинге 9 показана XSL-трансформация. Листинг 9. XSL-трансформация (View.php)
Если в проекте задействованы более крупные команды, всё равно имеет смысл извлекать строки и генерировать XSL-шаблоны из главного шаблона. Это обычно выполняется при помощи системы управления глобализацией (globalization management system - GMS). Затем Web-разработчики имеют дело только с XSL-шаблонами по умолчанию на предпочитаемом на предприятии языке, а переводчики используют функции системы управления, и, возможно, системы машинного перевода типа SYSTRAN. После окончания разработки, когда приходит время выпускать продукт, типичный процесс локализации может выглядеть следующим образом:
ЗаключениеВ такой короткой статье невозможно рассмотреть все трудности, с которыми вы можете столкнуться. Например, я не затрагивал работу с кодировками, датами, валютами и числами вообще, а также адресами и телефонными номерами. В большинстве случаев нужно в правильном формате вывести даты и валюты для локали. Также следует понимать, как проверять и интерпретировать суммы в валюте и даты, когда пользователи из разных стран впечатывают их в форму.Тем не менее, представленные приёмы позволят вам выполнять 80 процентов того, что необходимо сделать для локализации приложения. Если вы работаете с уже существующим приложением и имеются временные и бюджетные ограничения, сконцентрируйтесь на менее амбициозном подходе - модернизации. Если же вы разрабатываете новое приложение или имеете достаточные ресурсы для локализации существующего, не бойтесь быть более агрессивными, если это окупится. В результате вы получите не только безупречно локализованный продукт, но и значительно облегчите работу людям, которые будут осуществлять поддержку приложения, что бы им не пришлось делать - исправлять ошибку или добавлять новую функцию. Web-сервисы Java, часть 3: Связывание данных в Axis2 (исходники). Не повторяйте DAO!. Организация контента с помощью категорий Atom (исходники). XML и Java: Возвращение к основам (исходники). Введение в WML (исходники, документация). Главная » Xml |
© 2024 Team.Furia.Ru.
Частичное копирование материалов разрешено. |