Моя реализация локализации интерфейса в PHP

    Текущее положение дел такое, что очень часто приходится реализовывать мультиязычность в своих работах. Вроде бы техники хорошо описаны и проблем не должно быть, но я решил пойти своим путем.

    Сразу хочу огоровить — к тому варианту, который описан ниже я пришел сам и это касается только надписей/статического контента. Возможно существует такая реализация, но я с ней не знаком.

    На текущий момент мне известны такие реализации:
    • В файле, предположим, ru.php есть код: $language['site_title'] = 'Заголовок сайта'; В php или smarty используем этот массив и выводим текст чем-то похожим на {$language.site_title}
    • Использование расширения GetText (с функцией для smarty)
    • Использование smarty config (или реализации мультиязычности в шаблонизаторе quicky) (на самом деле, по моему, это вариации первого варианта)
    • Использование функций в smarty, с которой идет обращение к базе данных или глобальной переменной (фактически тоже вариации на тему первого пункта)

    Теперь описание моего варианта.
    Есть таблица надписей (phraze_id, language_id, value) в которой хранится весь статический контент сайта, так-же есть таблица языков (language_id, title). Это те таблицы с которыми мы будем работать. Теперь рассмотрим папку с шаблонами. Есть папка, предположим users в которой хранятся исходные шаблоны (templates/users) и есть папка временных шалонов (tmp/users). Теперь самый интересный момент. В исходных шаблонах на месте надписей пишем что-то типа [phraze{site_title}]. При изменении надписей в админке или по крону (это уже частная реализация) я перегенирирую шаблоны (заменяю [phraze{site_title}] на «Заголовок сайта» ) и схораняю измененный шаблон в папке tmp/users/ru или tmp/users/en в зависимости от языка. Тут надо только «сказать» smarty откуда брать шаблоны. Такая реализация позволяет избежать расходов на постоянный вызов функции/доставания с базы и делать это только по определенному событию.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 10

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Да, в php фалах доставали с кеша и я согласен что это минус
          0
          ну и тут главное сама технология. Реализация конечно может отличаться ))
        +2
        Это не мультиязычность - это локализация интерфейса.
          0
          вообще-то согласен ) Просто там где я работал это считали мультиязычностью... приелось уже и иногда делаю вот такие ошибки в описании. Исправлю
            0
            тег забыли обновить
          0
          А я делаю так:
          1. у меня есть класс шаблонизатора, который по большому счёту состоит из одного метода и приватного свойства, в которое пишется кэш. Этот метод принимает на вход имя файла и массив и заменяет в HTML-шаблоне все <%переменная%> на значения массива с ключём "переменная".
          2. В самом коде формируется этот массив.
          3. Перед вызовом Parser::parse($skin, $values) достаточно проинклюдить соответствующий языковой файл и сделать $values = array_merge($LANG, $values)
          В результате: код чист от представления, представление чисто от языко-зависимых данных, размер кода минимален, логика отделена от представления (нет всяческих богомерзких {section name=user_loop loop=$users})
            0
            А в чем превосходство вашего способа над обычным "en.module.conf", "ru.module.conf"?
              0
              Для меня превосходство было в том, что не вызывались какие-то ф-ции smarty для вывода надписей, а. так как надписей было много - такая реализация помогла немного снизить нагрузку. Возможно стоит провести тестирование скорости различных способов что бы сравнить
              0
              Автор забыл букву «ц» в заголовке))

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое