Долгий путь к языкам
Я уже довольно давно обдумываю идею, которая казалась одновременно интересной и сложной: что было бы необходимо для достижения многоязыковой поддержки моего веб-приложения с минимальными затратами на обслуживание? Также с учетом затрат в качестве основного ограничения (на этом сайте нет рекламы и вообще не используется отслеживание, поэтому здесь нет поступающей выручки), как могло бы выглядеть действительное решение?
План
Все начинается и заканчивается используемой системой перевода. Благодаря использованию Ubuntu в качестве одного из моих ежедневных драйверов, я однажды обнаружил в магазине приложений симпатичное маленькое приложение под названием «Argos translate», которое представляет собой движок перевода с открытым исходным кодом, построенный на последних моделях машинного обучения, подобных тем, что используются в DeepL . Если вы не знакомы с DeepL, это отличный переводчик, который можно бесплатно использовать на своем веб-сайте.
Но вернемся к Argos: взглянув на соответствующий репозиторий, я увидел, что есть также доступная OSS-библиотека python-lib, которая хорошо вписывается в автономную среду. Поработав некоторое время, я решил взглянуть на некоторых переводчиков через предложения SaaS, поскольку весь процесс установки argos translate не прошел так хорошо, как я надеялся.
Поэтому я установил другой сервис, Cloud Translations от GCP, который предлагает 500 000 символов бесплатно в месяц, а затем взимает определенную плату за каждые 1000000.
Все дело в кешировании
Благодаря настройке Next.js с ISG (инкрементное создание сайта) я могу вызывать переводы для каждой страницы по запросу, что значительно упрощает планирование, поскольку не требуется выполнять одно развертывание со всеми переводами сразу.
Тем не менее я не знал, как обрабатывать кеширование переведенных строк. Конечно, пограничная сеть Vercel (где размещается этот PWA) может полностью решить эту задачу. Но я хотел, чтобы развертывания не зависели от переводов. вот почему я создал один дополнительный уровень кеширования с помощью простого экземпляра Firestore, также размещенного на GCP.
Самой большой проблемой был синтаксический анализ + замена содержимого блока для каждой статьи. Если не знаешь. Контент блока описывает фактическое тело статьи, которое я создаю в CMS. После перевода эти блоки не являются обычным текстом, а каждый из них встроен в специальную структуру данных, позволяющую хранить семантическую информацию или метаданные. Надежное обнаружение и перевод только релевантных строк было одной из важнейших частей этой реализации.
Один мужчина, 12+ языков
Поддерживаемые языки (в настоящее время):
- "en": английский
- "de": немецкий
- "fr": французский
- "es": испанский
- "eo": эсперанто
- "эль": греческий
- "ja": японский
- «ru»: русский
- «привет»: хинди
- "он": иврит
- "tr": турецкий
- "af": африкаанс
- "ar": арабский
- «ко»: корейский
Чтобы протестировать различные варианты, просто поместите код языка после базового URL. Например: «https://flaming.codes/fr». Вот и все!
Подводя итог моей реализации, установка выглядит так:
- каждая страница статически строится не реже, чем каждые 4 часа, но только по запросу; это означает, что новый перевод выполняется не чаще чем каждые 4 часа для данного сайта.
- сами переводы сначала загружаются из Firestore; только если ничего не доступно, строки переводятся и кешируются в Firestore
Эта настройка работает настолько хорошо, что я не буду использовать какие-либо переводы классическим способом, например создание вручную json-файлов, в которых хранятся пары "ключ-значение". Я буду использовать Cloud Translation API для всего, что нужно интернационализировать, чтобы сделать его полностью динамичным. Благодаря этим изменениям на момент написания PWA насчитывает около 430 страниц.
Каждая страница переводится с английского на 13 других языков, которые представляют собой наиболее распространенные, а также те, которые расположены по всему миру между ними. Посмотрим, как он будет развиваться!
- Tom
