Обновление: с PoC на WiP в виде набора маленьких библиотек и утилит

Если hyperHTML поразил вас своим революционным использованием шаблонных литералов, вы, возможно, также будете рады обнаружить этот небольшой трюк, основанный на TL.

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

Как? Попробуйте ввести в консоли следующее: i18n`Hello ${'World'}` и увидите, что появится строка "Hello World".

Понятно? Хороший! Мы только что открыли для себя все необходимое, чтобы добавить i18n наверху.

Обещанные 10 строк

Я знаю, что код компактен, и мы упускаем некоторые дополнительные детали, но как только у нас появится способ настроить этот i18n.db объект, вы увидите, что на самом деле это действительно то, что нам нужно для написания красивого семантического кода, который будет переводить для нас прозрачно.

Настройка базы данных

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

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

и это самый простой способ, который я мог придумать:

Вышеупомянутую функцию не нужно обслуживать вместе с i18n, ее можно использовать только в автономном режиме или как функциональность интерфейса командной строки для настройки переводов.

Следуя примеру настройки «Hello World» на разных языках:

Если вы сейчас отметите объект i18n.db, вы увидите, что все на месте, и все также можно сохранить как JSON.stringify(i18n.db).

Используя эти десять строк кода

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

Это означает, что мы можем написать все приложение на английском языке и предложить несколько версий языка, просто изменив i18n.locale информацию.

Что нового или особенного?

Вот краткий список возможностей по сравнению с обычными решениями:

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

Гипотетические часто задаваемые вопросы

  • Совместимо ли оно с en-GB и en-US? Да, если у вас есть эти записи в базе данных, вы установили их через i18n.set("en-GB")`...`.for(…) и у вас есть значение по умолчанию i18n.locale = "en-GB"
  • как можно наращивать базу данных? Вы обслуживаете только один язык по умолчанию и загружаете любой другой по запросу. i18n.db - это общественное достояние, которое вы можете обогащать по мере необходимости. Как только новый язык будет установлен, вы сможете Object.assign(i18n.db, itIT), и {"it-IT":{}} локаль будет скопирована поверх исходной базы данных.
  • мне нужна глобальная функция? Как хотите. Если вам нужна одна и та же функция для всех модулей, и один из них отвечает за загрузку / обогащение нужной базы данных для всех из них, вы также можете использовать модули.
  • Будет ли работать, если я перенесу литералы шаблона? Да
  • Как это повлияет на производительность? Это зависит от ситуации. База данных обязательно нуждается в обязательном сжатии GZip, иначе будут загружаться повторяющиеся фрагменты. Однако создание правильного вывода после загрузки базы данных должно быть таким же быстрым, если не быстрее, чем любое другое решение i18n среды выполнения.

Выдающиеся вопросы

Теперь, когда мы ознакомились с концепцией, необходимо рассмотреть или создать различные вещи, чтобы сделать эту модель готовой:

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

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

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

Если у вас уже есть подобное решение, поделитесь им, потому что я с удовольствием им воспользуюсь!