Как Вы преобразовали бы существующее ранее веб-приложение в многоязычное?

Question

Как Вы преобразовали бы существующее ранее веб-приложение в многоязычное?

Я помещаю превосходный ответ JLBorges на аналогичный вопрос дословно из cplusplus.com, так как это наиболее краткое объяснение, которое я прочитал по этому вопросу.

] В шаблоне, который мы пишем, есть два типа имен, которые можно использовать - зависимые имена и не зависимые имена. Зависимое имя - это имя, которое зависит от параметра шаблона; неизменяемое имя имеет то же значение, независимо от параметров шаблона.

Например:
template< typename T > void foo( T& x, std::string str, int count )
{
    // these names are looked up during the second phase
    // when foo is instantiated and the type T is known
    x.size(); // dependant name (non-type)
    T::instance_count ; // dependant name (non-type)
    typename T::iterator i ; // dependant name (type)

    // during the first phase, 
    // T::instance_count is treated as a non-type (this is the default)
    // the typename keyword specifies that T::iterator is to be treated as a type.

    // these names are looked up during the first phase
    std::string::size_type s ; // non-dependant name (type)
    std::string::npos ; // non-dependant name (non-type)
    str.empty() ; // non-dependant name (non-type)
    count ; // non-dependant name (non-type)
}
То, что зависит от зависимого имени, может быть чем-то другим для каждого конкретного экземпляра шаблона. Как следствие, шаблоны C ++ подвержены «двухфазному поиску имен». Когда шаблон сначала анализируется (до того, как выполняется какое-либо создание), компилятор просматривает не зависящие имена. Когда происходит конкретное создание шаблона, параметры шаблона известны к тому времени, и компилятор ищет зависимые имена.

На первом этапе анализатор должен знать, является ли зависимое имя именем типа или имени не-типа. По умолчанию зависимым именем считается имя не-типа.

Использовать ключевое слово typename только в объявлениях шаблонов и определениях, приведенных ниже.
blockquote>
у вас есть квалифицированное имя, которое относится к типу и зависит от параметра шаблона.

22

internationalization symfony php

задан TRiG 29 July 2013 в 17:08

6 ответов

Работа с файлами языков.

Замена каждая текстовая строка переменной
Создает один файл языка на язык, и в нем определяют каждую переменную с их соответствующим текстом. (french.inc, dutch.inc...)
Включают правильный файл в каждую страницу.

Это для небольших сайтов.

При становлении более крупными, замените файлы DB.:)

15

ответ дан 29 November 2019 в 05:19

Вы могли посмотреть Zend_Translate, это - довольно всестороннее, хорошо зарегистрированное и полное качество кода, является большим. Это также позволяет Вам использовать объединенный API для gettext, csv, дб, ini файл, массив или независимо от того, что Вы заканчиваете тем, что сохранили свои переведенные строки в.

кроме того, посмотрите на этот поток: , Что такое хорошие инструменты/платформы для i18n php кодовой базы? . Это кажется подобным Вашему вопросу.

2

ответ дан 29 November 2019 в 05:19

Если это - поддержка многобайтового символа тогда, могло бы стоить проверить функции байтовой строки в PHP:

http://uk.php.net/manual/en/book.mbstring.php

Они лучше обработают многобайтовые символы.

1

ответ дан 29 November 2019 в 05:19

Я использую параметр hl и gettext, комбинируя уже существующие переводы движка с собственным .po, что заставляет новые переводы и языки появляться, когда движок или мой пример django / gae добавляет:

{% get_current_language as LANGUAGE_CODE %}{{ LANGUAGE_CODE }}{% get_available_languages as LANGUAGES %}{% for LANGUAGE in LANGUAGES %}{% ifnotequal LANGUAGE_CODE LANGUAGE.0 %}{{ LANGUAGE.0 }}{% endifnotequal %}{% endfor %}

] Таким образом, отказ от дублирования и полное использование уже имеющихся переводов позволяет указать здесь отсутствующие, например, арабские названия месяцев, которые будут появляться непосредственно либо при добавлении команды движка, либо при app

-2

ответ дан 29 November 2019 в 05:19

Важно отметить, что перед переводом необходимо выполнить два шага:

Интернационализация: то есть, чтобы ваш сайт мог работать на нескольких языках.
Локализация: это включает перевод ваших текстов (полученных на шаге 1) на каждый язык, который вы план поддержки

См. дополнительную информацию в Википедии .

Шаг 1 потребует от вас принять во внимание тот факт, что некоторые языки пишутся справа налево (RTL) и неевропейские символы, такие как японский или Китайский язык. Если вы не планируете использовать эти языки и символы, это может быть проще.

Для такого типа ситуаций я бы предпочел иметь языковой файл (фактически столько языковых файлов, сколько языков, которые я планирую поддерживать, назвав каждый как langcode.php , как в en.php или fr.php ) с ассоциативным массивом, содержащим все тексты, используемые на сайте. Процедура будет выглядеть следующим образом:

Просканируйте свой сайт на предмет каждого отдельного текста, который необходимо локализовать
Для каждой страницы / раздела я бы создал массив $ lang ['sectionname'] [] массив
Для каждого текста я бы создал $ lang ['sectionname'] ['textname'] entry
Я бы создал Lang.php класс, который получил бы lang параметр при создании экземпляра, но будет иметь значение по умолчанию, если не получено lang (этот метод загружает langcode. php в зависимости от параметра или значения по умолчанию в зависимости от вашего предпочтительного языка)
Класс будет иметь метод setPage () , который получит страницу / раздел, который вы будете отображать
класс будет иметь метод show () , который будет получать отображаемый текст ( show () будет вызываться столько раз, сколько текстов показано на данной странице ... show () является своего рода оболочкой для echo $ lang ['mypage'] ['mytext'] )

Таким образом, у вас может быть столько языков, сколько вы хотите в очень простой способ. У вас даже может быть языковой администратор, где вы открываете страницу своего базового языка (на самом деле вы просто рекурсивно читаете массивы и отображаете их в текстовых областях), а затем можете «Сохранить как ...» на другом языке.

Я использую аналогичный подход на моем сайте . Хотя это всего одна страница, но я сделал многостраничных сайтов с этой идеей.

Если у вас есть контент, отправленный пользователями, или какая-то довольно сложная CMS, это была бы другая история. Вы можете поискать фреймворки для i18n (на ум приходит Drupal).

3

ответ дан 29 November 2019 в 05:19

Другие вопросы по тегам:

internationalization symfony php

Похожие вопросы:

score 11 · Accepted Answer

Есть несколько способов решить эту проблему. Ни один из них не является «лучшим способом», и все они имеют проблемы в краткосрочной или долгосрочной перспективе. Первое, что нужно сказать, это то, что многоязычные сайты - это непросто, переводчики и прекрасные люди, но с ними сложно работать, и большинство программистов видят в этой проблеме чисто техническую проблему. Существует также другое измерение, выходящее за рамки этого ответа, относительно того, переводите ли вы или локализируете. Это включает изучение культурных традиций целевой аудитории, а затем адаптацию языка, стиля, макета, цвета, шрифта и т. Д. К этой культуре. Наконец, не используйте машинный перевод (машинный перевод) ни для чего серьезного или если он должен быть точным, и при найме переводчиков убедитесь, что они переводят с иностранного языка на свой родной язык, что означает, что они понимают все нюансы целевого языка.

Верно. Решения. Исходя из того, что вы не хотите переписывать сайт, просто клонируйте имеющийся у вас сайт и переводите копии на целевой язык. Предполагая, что база кода стабильна, вы можете использовать VCS для управления любыми изменениями кода. Вы можете настроить отдельные части сайта, чтобы они соответствовали целевому языку, например, текст на французском языке в среднем на 30% больше, чем эквивалентный текст на английском языке, поэтому использование одного сайта для доставки означает, что у вас могут быть (будут) проблемы с форматированием и вам потребуется поменять местами разные файлы css в зависимости от языка. Это может показаться неуклюжим способом сделать это, но в таком случае как долго будут существовать сайты? Затраты на управление таким способом могут быть меньше, чем при использовании других вариантов.

Второй способ без перестройки. Заменить весь контент на текущем сайте тегами, а затем поместить другой язык в таблицы файлов или БД, нюхать желаемый язык пользователя (есть ли у вас зарегистрированные пользователи, которые могут сделать выбор, или вы хотите получить тег языка браузера, или это будет URL-адрес dot-com dot-fr, dot-de, который сделает выбор) и затем замените теги на целевой язык. Затем вам нужно отдельно решить проблемы с размером и изображением. Это решение действует, когда фреймворки, такие как Symfony и Zend, реализуют l10n.

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

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