Weblate の基本#

プロジェクトとコンポーネントの構造#

Weblate では、翻訳はプロジェクトとコンポーネントで構成されています。各プロジェクトには複数のコンポーネントを含めることができ、コンポーネントには個々の言語への翻訳を含めることができます。コンポーネントは、翻訳可能な 1 つのファイル（例: GNU gettext や Android 文字列リソース）に対応します。プロジェクトは、コンポーネントを論理的なまとまりに分類（例えば、1 つのアプリケーション内で使用するすべての翻訳をグループ化）するのに便利です。

内部ではデフォルトで、各プロジェクトごとに、共通する文字列の翻訳はプロジェクト内の他のコンポーネントに自動反映させます。これにより、反復や複数バージョンの翻訳の負担を軽減します。コンポーネント独自の翻訳が望ましい場合は、翻訳の反映を コンポーネント構成 ごとに無効にできます。

リポジトリの統合#

Weblate は上流のバージョン管理リポジトリと統合するように構築されています。継続的な現地語化 にはビルディング ブロックと、それらの間で変更がどのように流れるかについて説明されています。

参考

アーキテクチャの概要 は、Weblate 内部の動作原理を説明します。

User attribution#

Weblate keeps the translations properly authored by translators in the version control repository by using name and e-mail. Having a real e-mail attached to the commit follows the distributed version control spirits and allows services like GitHub to associate your contributions done in Weblate with your GitHub profile.

This feature also brings in risk of misusing e-mail published in the version control commits. Moreover, once such a commit is published on public hosting (such as GitHub), there is effectively no way to redact it. Weblate allows choosing a private commit e-mail in アカウント to avoid this.

Therefore, admins should consider this while configuring Weblate:

  • Such a usage of e-mail should be clearly described in service terms in case such document is needed. 法的文書 can help with that.

  • PRIVATE_COMMIT_EMAIL_OPT_IN can make e-mails private by default.