Как устроена локализация Obsidian и почему туда стоит заглянуть

Вы когда-нибудь задумывались, как популярные инструменты вроде Obsidian умудряются поддерживать десятки языков, сохраняя при этом темп выпуска обновлений? Ответ довольно прост и одновременно изящен: они отдали это на откуп сообществу. Репозиторий obsidian-translations — это не просто склад текстовых файлов, а живой пример того, как организовать процесс перевода сложного продукта силами волонтеров без лишней бюрократии.

Я наткнулся на этот проект, когда искал примеры грамотной структуры l10n (localization) для своего пет-проекта. Оказалось, что здесь можно не только помочь с переводом на русский, но и подсмотреть несколько полезных приемов автоматизации и организации работы с контентом.

Что внутри репозитория

По сути, это центральный хаб для всех текстов, которые вы видите в интерфейсе Obsidian и на их официальном сайте. Разработчики выбрали максимально прозрачный путь: вместо использования тяжеловесных платных платформ для локализации, они держат все в обычном Git-репозитории.

Кому это может быть полезно? Во-первых, фанатам Obsidian, которые хотят видеть качественный перевод. Во-вторых, разработчикам, которые планируют выводить свои приложения на международный рынок и не знают, с чего начать организацию файлов.

Как это работает на практике

Процесс перевода здесь максимально упрощен. Нет нужды даже клонировать репозиторий через терминал — все правки можно вносить прямо в веб-интерфейсе GitHub. Это снижает порог входа для тех, кто хорошо знает язык, но не очень дружит с консолью.

Формат файлов

Вместо привычных JSON или YAML, для приложения используются обычные .txt файлы со специфической структурой блоков. Выглядит это примерно так:

[setting.label-example]
original=The original english text.
translation=Переведенный текст.

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

Работа с переменными

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

[setting.label-welcome]
original=Welcome, {{name}}!
translation=Добро пожаловать, {{name}}!

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

Тестирование «на лету»

Одна из самых крутых штук в этом проекте — возможность моментально проверить свой перевод в самом приложении Obsidian. Не нужно ждать, пока ваш Pull Request примут и выпустят новую версию.

В Obsidian можно открыть консоль разработчика и вызвать функцию: selectLanguageFileLocation()

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

Сайт тоже здесь

Интересно, что переводы для сайта obsidian.md лежат в этом же репозитории, но в папке website/. Там уже используются JSON-файлы, так как сайт генерируется статически. Для контроля качества разработчики добавили небольшой скрипт на Node.js:

node scripts/check-website.mjs

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

Почему это заслуживает внимания

Проект obsidian-translations наглядно показывает, что для локализации крупного продукта не всегда нужны сложные enterprise-решения. Иногда достаточно:

• Хорошо структурированных текстовых файлов.
• Понятных инструкций в README (здесь они действительно пошаговые).
• Инструмента внутри самого приложения для быстрой проверки правок.

На текущий момент в репозитории более 700 форков и активное сообщество. Даже если вы не собираетесь ничего переводить, стоит изучить их структуру папок и скрипты проверки — это хороший стандарт для open-source проектов, претендующих на глобальный охват.

Если вы пользуетесь Obsidian и замечали мелкие неточности в интерфейсе — теперь вы знаете, что исправить это можно буквально за пару минут через обычный Pull Request. А для разработчиков это отличный кейс того, как сделать вклад в проект максимально простым и приятным.