Другой подход к переводу веб-приложений

Question

Я создал несколько веб-сайтов и приложений с поддержкой нескольких языков, где я использовал языковые XML-файлы и ключевое слово внутри своего кода. Я считаю, что для моего веб-приложения этот метод - отстой. Я люблю читать и понимать мой HTML-код. Этот код не имеет никакого смысла:

<h1><?= translate('main_headline'); ?></h1>

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

Мое решение (я только что написал простой тестовый парсер PHP час назад, как вы думаете, это будет работать в крупномасштабном проекте?)

Я использую английский в качестве базового языка, и вот как выглядит мой исходный файл:

<h1>{{ I love colors }}</h1>

Мой синтаксический анализатор будет использовать текст (реальный текст) в качестве ключа для массива словаря. В этом примере я перевожу с английского на американский английский.

$dictionary['I love colors']['en_GB'] = 'I love colours'

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

Существует гораздо больше, таких как кэш, резервные копии, хранилище словаря и т. Д. Как вы думаете, это будет работать в крупных проектах? Это там что-то я не учел?

Answer 1

Один недостаток в том, что для двух разных частей приложения могут потребоваться разные переводы для одного и того же слова / фразы. Наиболее очевидным примером является гомограф , например, «закрыть» (рядом) и «закрыть (закрыть), но есть и другие возможности.

Пример надуманной фразы:

В одной части, «Я люблю свои цвета» просто относится к буквальным цветам.
В другом это означает «я люблю свой флаг»

В случае, если:

$dictionary['I love my colors']['es_ES']

be "Me encantan mis colores" или "Me encanta mi bandera". Это должно быть как-то так.

Именно поэтому в каталоге сообщений обычно используется уникальный идентификатор или номер строки.

Answer 2

Некоторые соображения и идеи.

• Сократите повторное использование фразы до минимума. Мой опыт показывает, что обслуживание переводов намного легче.

• Синтаксис должен быть независимым от языка, поскольку вы, скорее всего, будете переводить PHP, JS, HTML и т. Д. С их собственными типами файлов. Другими словами, не только шаблоны PHP нуждаются в разборе, .js файлы, вероятно, также будут содержать тексты.

  {{ <img src="heading-en.png" alt="Heading" /> }}
  alert('{{ some text }}');
  

• Приведенный выше пример alert прервется, если текст перевода, содержащий ', будет каким-то образом обработан.

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

  {{ <?= $num ?> apples cost <span class="price"><?= $price ?></span> with <?= $discount ?>% discount }}
  

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

  {{ 
      %num% apples cost <span class="price">%price%</span> with %discount%% discount
      } num:<?= $num ?>
      , price$:<?= $price*$discount ?>
      , discount:<?= round($discount*100) ?>
  }
  

  .. где цена $ может означать, что это цена, и конвертирована в правильную валюту.

• Валюта должна быть обработана.

Просто пара вещей, которые всплыли на ум. Удачи; -)

Answer 3

Я предпочитаю использовать готовые теги для такого рода вещей, чтобы я мог включать заметки о контексте и значении, и такие вещи очень полезны для переводчиков.Например:

<h1><l10n id="blah" notes="This is a header for a section on blah blah, title case">Blah Blah</l10n></h1>

Аналогично, вы можете использовать готовые атрибуты для alt и title текста.

Вам нужно быть осторожным с различными контекстами (HTML, <script>, <style>, PHP, различные языки шаблонов, ...) хотя.Вы также должны быть осторожны с порядком слов и гендерными проблемами, но это стандартные проблемы L10N.

Затем вы можете предварительно обработать все переведенные файлы в отдельные каталоги (по одному на язык) и избежать накладных расходов при создании переводов намуха.

Answer 4

РЕДАКТИРОВАТЬ: ответы других теперь лучше, чем у меня:)

Я не знаю никаких проблем со вторым вариантом (но у меня также нет опыта работы с I18N).

Единственная потенциальная проблема, которую я вижу со вторым вариантом, - это обратимость. Если кто-то возвращается и меняет текст на «Я люблю цвета», то кто-то должен всегда убедиться, что он вернется к переводу, и изменить английский ключ. Однако тот факт, что вы делаете i18n, заставляет меня предположить, что уже есть кто-то, чья работа заключается в том, чтобы заниматься скукой перевода, поэтому я бы не стал это рассматривать как проблему.

Answer 5

Да, это хороший подход.

Мы используем что-то вроде: || 4332 || Я люблю цвета ||

Затем вы можете просто разобрать файл, извлечь все идентификаторы (4332) и посмотреть перевод в базе данных.