наилучшая практика для интернационализации PHP-кода с белыми метками - PullRequest
2 голосов
/ 03 февраля 2012

У меня есть кодовая база, которую можно настроить для разных клиентов.В большинстве случаев это выполняется путем загрузки класса с константами, специфичными для каждого клиента, но с тем же именем класса.Столкновение имен классов управляется, и, очевидно, загружается только одно.

class Customer () {
    const CUST_NAME = 'Alpha Corp.';
}

class Customer () {
    const CUST_NAME = 'Beta, Inc.';
}

Для каждого клиента я также хочу, чтобы код был интернационализирован.Таким образом, программа может извлекать отображаемый текст из источника, зависящего от языка, но при этом сохранять динамичность в отношении информации, специфичной для клиента.Предположим, что информация о клиенте безразлична к i18n.Это уменьшает количество файлов с одного на клиента для каждого языка до одного на язык.Желаемый результат заключается в реализации чего-то похожего на

// in separate language files:
$greeting = 'Hello. Welcome to ';
$greeting = 'Hola. Bienvenido a ';

// in front-end
$greeting = get $greeting in desired language;
echo $greeting, Customer::CUST_NAME, "\n";

. Лучшее решение, которое я могу придумать для удовлетворения этих требований, - это класс i18n (или семейство классов), который будет работать с несколькими клиентами и / или несколькими языками.Однако вызов методов является дорогостоящим по сравнению с строковыми литералами или константами.Методы будут объединять переводы из констант или внешних источников и объединять их со значениями из класса Customer.(Я сейчас застрял с PHP 5.2, поэтому тонкости heredoc для свойств / констант класса недоступны.)

class i18n_en () {
    const GREETING = 'Hello. Welcome to ';

    static public function getGreeting () {
        return self::GREETING . Customer::CUST_NAME;
    }
}

В качестве альтернативы я могу написать скрипт для «шаблонного подхода», в котором яподдерживать файл шаблона класса с текстовыми заполнителями.Пользовательские файлы создаются во время создания клиента из этих шаблонов.Было бы легко создавать или повторно генерировать файлы по мере необходимости, но я вернулся к необходимости отдельного файла для каждого клиента для каждого языка.Таким образом, это не удовлетворяет мою потребность так хорошо.

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

Ответы [ 2 ]

5 голосов
/ 04 февраля 2012

Существует два проверенных и настоящих метода интернационализации PHP.

Наиболее распространенным является создание огромных языковых массивов, например, так:

define('MSG__GREETING', 1);

$lang['en_US'] = array(MSG__GREETING => 'Hello, and welcome to ');
$lang['fr_FR'] = array(MSG__GREETING => 'Bonjour, et bienvenue à ');

$selectedLang = 'fr_FR';
echo $lang[$selectedLang][MSG__GREETING] . 'Fhloston Paradise';

К сожалению, это очень утомительно очень быстро.

Идеальный метод, который я использовал много раз, - это принятый метод интернационализации для приложений Linux: il8n, через PHP-расширение gettext .

С этим методомв основном вы в конечном итоге делаете такие вещи:

setenv('LANG=fr_FR');
echo _('Hello, and welcome to ') . 'Fhloston Paradise';

, а затем в файлах il8n (называемых .po) у вас есть каждый перевод.На самом деле гораздо проще поддерживать и расширять в долгосрочной перспективе, особенно потому, что вы можете просто отправлять свои .po файлы по электронной почте различным переводчикам, и они просто заполняют пробелы, как это было бы ... без навыков кодирования.

Вот учебник, с которого можно начать: http://kunststube.net/frontback/

1 голос
/ 03 февраля 2012

Лично при работе с интернационализацией я всегда использовал шаблоны, в частности, Smarty - http://www.smarty.net/ и создаю шаблон на основе языка.Вы также можете использовать ключи перевода в базе данных, бывшей таблице с ключом, языком, столбцами перевода, которые можно кэшировать таким образом, чтобы не вызывать тонны методов.Кроме того, вы можете кэшировать вывод всех методов перевода в памяти, используя memcached.Тонны способов.Надеюсь, что некоторые из них помогут немного.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...