Локализация сайта

Встала задача перевести сайт на множество языков мира. Первым в голову приходит такой способ: создать статический класс, в который заносим идентификатор языка, и который содержит функцию, возвращающую текст, в зависимости от переданного аргумента (пути к этому тексту). Сами локализационные файлы содержат массив текстов. Скажем нужно локализовать страницу настроек, поле «имя пользователя», передаем в функцию путь Settings/UserName и она возвращает значение $localize[«Settings»][«UserName»];

При таком подходе возникает несколько вопросов:
1. Как эффективнее хранить эти локализационные массивы: в файлах php и подключать (include_once) определенный файл в зависимости от языка или в json с применением memcache и выбирать нужный?
2. Как определить системный язык пользователя (причем независимо от операционки)?
3. Возможно есть более эффективный подход?

P.S. Как вариант смотрится дата модификации php скрипта, и если она новее, чем та, что в memcache, то массив сериализуется и помещается в memcache. Либо лучше заранее сериализовать локализационные файлы перед загрузкой на сервер?
  • Вопрос задан
  • 10974 просмотра
Пригласить эксперта
Ответы на вопрос 9
Kyborg2011
@Kyborg2011
1. Как эффективнее хранить эти локализационные массивы: в файлах php и подключать (include_once) определенный файл в зависимости от языка или в json с применением memcache и выбирать нужный?

По моему БД MySQL удобнее всего в данном случае.

2. Как определить системный язык пользователя (причем независимо от операционки)?

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

3. Возможно есть более эффективный подход?

Если писать с нуля, то эффективнее не знаю, если на Zend Framework, то там специальные классы уже разработаны.
Ответ написан
Chvanikoff
@Chvanikoff
Рекомендую взглянуть на реализацию из фреймворка Kohana.
github.com/kohana/core/blob/3.0/develop/classes/kohana/i18n.php
github.com/kohana/core/blob/3.0/develop/base.php

В принципе, разобраться не сложно, я думаю.
В приложении, например, пишете:
//установка языка
I18n::$lang = 'ru-ru' //к примеру
//где нужен перевод пишете, например
__('hello :username', array(':username' => $username));

И создаете, к примеру, файл ru-ru.php (класс Kohana_I18n написан так, чтобы искать этот файл в соответствии со своей архитектурой — этот момент Вам и придется редактировать, если захотите использовать) с содержанием:
<?php

return array(
    'hello :username' => 'Привет, :username!',
);
Ответ написан
1. Недавно на Хабре как раз была статья про оптимизацию РНР. Быстрее всего хранить в файле, подключаемом. Его ведь тое можно генерировать из админки. Так что это и удобно.
2. Либо по айпишнику (в инете много геолокационных баз), либо по заголовкам браузера (Accept-Language).
3. С нуля именно так юыстрее всего влиться, наверное. Можно, конечно перерабатывать страницы заменять соот. слова. Но Это будет. наверное, медленно. Хотя с кэшированием и проч…
Ответ написан
Комментировать
@Robotex Автор вопроса
В заголовках браузера какой язык? Браузера или ОС?

У меня стоит украинский язык в Убунте и на пиратбее, фейсбуке, вконтакте автоматически выставляется украинский язык. А во в венде русский — соотвественно, везде русский. Как они это делают?
Ответ написан
Dennion
@Dennion
Разработчик PHPShop CMS.
Это правда еще не реализовано, но есть мыслишка сделать ленг-файл на лету, т.е. подключается скрипт, который проверяет все вхождения русские слова (изначально интерфейс написан на русском языке) и по мере обхода создает языковую карту, по аналогии
$localize[«Settings»][«UserName»]; в файл, например eng.php, далее вам остается лишь его заполнить по мере работы. Конечно все это нужно будет делать на UTF.

Плюсы
— не нужно париться с ленг-файлом и прописывать переменные в php файлы
— можно подключить неограниченное кол-во языков

Минусы
— уменьшение скорости ПО

Мысли по ходу

Со скорость можно поиграть и создавать еще сериализованный массив с привязкой по конкретным php (всякие окна редактирования и т.д.), те набор языковых переменных в таких файлах ограничен стандартным набором.

Языковые фразы нужно будет брать в тег span id=«lang», чтобы увеличить скорость.

PS Пока писал, прочитал выше коммент и понял, что это есть уже в Zend_Translate, сперли мою идею :)
Ответ написан
Комментировать
Dennion
@Dennion
Разработчик PHPShop CMS.
Перевод на лету, то лучше конечно результат в файлик писать, чтобы не тратить ресурсы каждый раз.

function translate($text) {
        $text = urlencode(win_utf8($text));
        $domain = "ajax.googleapis.com";
        $result='';
        $fp = fsockopen($domain, 80, $errno, $errstr);
        if (!$fp) {
            return exit("Ошибка соединения с сервером переводчика");
        } else {
            fputs($fp, "GET /ajax/services/language/translate?v=1.0&q=".$text."&langpair=ru%7Cen&callback=foo&context=bar  HTTP/1.0\r\n");
            fputs($fp, "Host: $domain\r\n");
            fputs($fp, "Connection: close\r\n\r\n");
            while (!feof($fp)) {
                $result.=fgets($fp, 1000);
            }
            fclose($fp);
        }

        preg_match('|"translatedText":"(.*?)"|is', $result, $locale);
        return $locale[1];
    }
Ответ написан
Комментировать
artoodetoo
@artoodetoo
В общем то Вы сами описали всё неплохо и можете обойтись без посторонних подсказок :) Буквально пара замечаний:

Сериализованные данные загружаются чуть-чуть быстрее кода на PHP. Если добавить к этому накладные расходы на memcache, весь профит может улетучиться. Тестируйте — это platform dependent.

Есть расширения PHP с быстрыми функциями сериализации/десериализации. Опять же выигрыш будет только для особых случаев, если данных реально _много_. Файлы переводов, скорее всего, не тот случай.
Ответ написан
Комментировать
@zavg
В Zend framework'e есть класс Zend_Translate. Он работает с разными вариантами представления данных, начиная от php-массива и csv-файла с разделителями и заканчивая ini-файлами, xml и файлами формата GetText.
Рекомендую для локализации именно последний вариант. Все локализационные данные обрамляются определенным образом в коде, специальная утилита (например, POEdit) сканирует файлы проекта на предмет появления новых значений и изменения старых, после чего появляется удобная таблица для ввода перевода. Таким образом, с помощью такой тулзы локализацию можно перепоручить переводчику вообще не имеющему отношение к проекту, коду и т.д.
Ответ написан
Комментировать
P0WERMIC
@P0WERMIC
видел, что делают даже так: ставят ссылку или выпадающий список выбора языка, а по щелчку скажем на китайский у пользователя сайт откроет в google translate
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы