А если мне надо два контекста? generic, типа ok или submit, и специфичный для компонента.

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

нормальный подход это запекать строки в бандл то есть делать обратный трансформ из t(string) -> string и то если нет динамики

контекст по хорошему должен наследоваться

плюс еще бывает rich-text

    <Trans i18nKey="userMessagesUnread" count={count}>
      Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>.
    </Trans>

когда тебе надо в переводимую строчку компоненты втыкать

это покроет 95%, а остальные уже по старому сделать

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

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

Ну и про компайл-тайм непонятно, что именно там можно делать.

На мой взгляд, всё, что может предложить фреймворк (не свелт даже, а саппер как раз) — это доставка ключей на клиент. Сейчас большинство решений топорные (выкачать весь JSON/менеджить их слайсирование руками/делать рест по получению ключей), а по уму надо чтобы минимальный набор ключей поставлялся на клиент вместе с компонентом.

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

это может значительно уменьшить бандлы =)

но их будет тогда хКолво языков

Мне кажется, это как раз относится к доставке ключей.
Кажется, что SSR вообще должен выполнять эту задачу на бэке под настройки юзера, а остальное должно как-то магически падать вместе с чанками компонентов.

возможно, но я согласен что саппер может взять на себя это и правильно организовать словари и их подгрузку

другое дело что возможности свелта позволяют только явно вызывать t что несовместимо с rich-text никак =)

Да, организация словарей, автоматическая сборка ключей из компонентов и разрешение конфликтов (ренейм или перенос в другой файл, скажем), доставка на клиент. Может быть, какие-то коммон-компоненты для роутинга (гет-параметры, ключ в пути, etc.). Всё остальное уже самому.

Так а системы перевода никакого решения для ричтекста не дают вообще.
Мы всю жизнь фигачим html-теги в строках для перевода, переводчики к этому уже давно привыкли. Ну а в свелте дальше, увы, {@html }, и никак иначе. Можно только как-то пострипать лишний мусор заранее.

хтмл теги в обошли, а как компоненты вставлять?

императивно, оф корс.