アクセス制御
Weblate は、インスタンス全体または限定した範囲でユーザーにアクセス権を割り当てるための、詳細な権限システムを搭載しています。
バージョン 3.0 で変更: Weblate 3.0 より前のバージョンでは、Django の権限システムのみをベースにしていましたが、現在は Weblate 専用に構築されています。古いバージョンを使用する場合は、使用するバージョンのドキュメントを確認してください。
シンプルなアクセス制御
あなたが Weblate のインストール全体を管理しておらず、特定のプロジェクトを管理するためのアクセス権だけを持っている場合（Hosted Weblate のように）、アクセスコントロールの管理オプションは以下の設定に限られます。複雑な設定を必要としないのであれば、これらの設定で十分でしょう。
プロジェクトのアクセス制御
注釈
この機能は、 Hosted Weblate で Libre プランを使用するプロジェクトでは利用できません。
プロジェクトごとに別の アクセス制御 設定を選択することで、ユーザーのアクセスを制限できます。使用可能なオプションは次のとおりです。
- 公開
公開、サインインしたすべてのユーザーが翻訳できます。
- 保護
公開、選択したユーザーのみ翻訳できます。
- プライベート
選択したユーザーのみ、表示および翻訳ができます。
- カスタム
ユーザー管理 の機能は無効になります。デフォルトでは、どのユーザーもプロジェクト上での全ての操作が禁止されます。すべてのパーミッションは カスタム アクセス制御 を使用して設定することが必要です。
アクセス制御 は、各プロジェクトの設定（管理 ↓ 設定）の アクセス タブで変更できます。
デフォルト値は DEFAULT_ACCESS_CONTROL で変更できます。
注釈
プライベート プロジェクトの場合でも公開される、プロジェクトに関する情報: インスタンス全体の統計と言語の概要には、アクセス制御の設定にかかわらず、すべてのプロジェクトの統計値が含まれています。この情報からは、プロジェクト名やその他の情報は分かりません。
注釈
公開、保護、および プライベート プロジェクトでユーザーがデフォルトで使用できる実際の権限のセットは、Weblate インスタンス管理者が カスタム設定 から再定義できます。
参考
プロジェクトごとのアクセス制御の管理
プロジェクトのアクセス管理 権限（参照: アクセス権および組込みロールの一覧）があるユーザーは、チームにユーザーを追加してプロジェクト内のユーザーを管理できます。最初のチームのアクセス権は Weblate によって自動生成されます。追加のアクセス権を設定すると、より詳細なアクセス制御ができます。チームには、言語と個別のアクセス権を設定して制限をかけられます（参照: アクセス権および組込みロールの一覧）。
プロジェクトごとに自動生成されるチームのアクセス権:
公開 、 保護 および プライベート プロジェクトのアクセス権:
- 管理
プロジェクトで使用できるアクセス権をすべて含みます。
- 査読（ review workflow が有効化されている場合のみ）
査読中に翻訳を承認するアクセス権。
保護 および プライベート プロジェクトのみのアクセス権:
- 翻訳
プロジェクトを翻訳し、オフラインで作成した翻訳をアップロードするアクセス権。
- 原文
原文（プロジェクトの設定 で許可している場合）および モノリンガル コンポーネント と原文情報を編集するアクセス権。
- 言語
翻訳言語を管理するアクセス権（翻訳の追加または削除）。
- 用語集
用語集を管理するアクセス権（エントリの追加、削除、またはアップロード）。
- 翻訳メモリ
翻訳メモリを管理するアクセス権。
- スクリーンショット
スクリーンショットを管理するアクセス権（追加または削除、原文への関連付け）。
- 自動翻訳
自動翻訳を有効にするアクセス権。
- VCS
VCS を管理し、リポジトリをエクスポートするアクセス権。
- 請求
請求情報と請求の設定をするアクセス権（参照: 請求）。
この機能は、プロジェクトにあるメニューの 管理 ↓ ユーザー から操作できる アクセス制御 のページで設定します。
チーム管理者
バージョン 4.15 で追加.
各チームには、チーム内のユーザーを追加および削除できるチーム管理者を設置できます。これは、自己管理型チームを構築する場合に便利です。
新しいユーザーの招待
また、既存のユーザーをプロジェクトに追加する以外に、新しいユーザーを招待することもできます。新しいユーザーは直ちに作成されますが、メールで送信された招待状のリンクを使用してサインインするまで、アカウントは無効の状態のままです。メールで招待するために、サイト全体のアクセス権は必要はありません、プロジェクト全体に対するアクセス権（例: 「管理」チームへの登録）で十分です。
ヒント
たとえ、招待したユーザーの招待期限が過ぎてしまっても、アカウントが既に作成されているため、パスワード リセット フォームを使用して、招待されたメールアドレスからパスワードを設定できます。
バージョン 3.11 で追加: ユーザーを招待するメールの再送信ができる（以前送信した招待を無効とする）。
同じ種類の招待状は、Users タブの management interface からサイト全体で使用できます。
ユーザーのブロック
バージョン 4.7 で追加.
プロジェクトで悪事を働くユーザーがいる場合、そのユーザーの投稿をブロックできます。ブロックされたユーザーは、権限があれば引き続きプロジェクトの閲覧はできますが、貢献はできなくなります。
プロジェクトごとのアクセス権の管理
Weblate のユーザー インターフェイスでは、プロジェクトごとに 保護 または プライベート に設定することや ユーザーの管理 ができます。
デフォルトでは、これを有効にしたプロジェクトにおいて、 デフォルト チーム ユーザー と 閲覧者 に与えられるアクセス権はこれらのチームの設定によって無効になります。しかし以下の カスタム アクセス制御 の説明にあるように、これらのチームの設定を変更したり、新しいチームを作成したり、コンポーネント単位で追加のカスタム設定を作成したりして、サイト全体でそのようなプロジェクトへのアクセス権を付与できます。
アクセス権を Weblate ユーザー管理画面から管理する主な利点の 1 つは、スーパーユーザー権限を付与せずに管理を他のユーザーに委任できることです。そのためには、プロジェクトの 管理 チームに追加します。
カスタム アクセス制御
注釈
この機能は、 Hosted Weblate で Libre プランを使用するプロジェクトでは利用できません。
権限システムはチームとロールに基づいています。ロールはアクセス権の組み合わせを設定し、チームはロールをユーザーと翻訳に結び付けます。詳しくは ユーザー、ロール、チーム、およびアクセス権 を確認してください。
現在のところ、Weblate のアクセス制御システムの最も強力な機能は、Django 管理画面 からのみ操作できます。Django 管理画面から、すべてのプロジェクトのアクセス権を管理できます。使用するために、カスタム access control に切り替える必要はありません。ただし、使用するにはスーパーユーザー権限が必要です。
実装の詳細には関心がなく、条件を満たす簡素なデフォルトの設定を作成するだけの場合、またはサイト全体のアクセス権で、インストールされた Weblate 全体（Hosted Weblate）にアクセスできない場合は、シンプルなアクセス制御 を確認してください。
共通設定
このセクションでは、一般的な設定の概要が含まれています。
サイト全体のアクセス権の管理
インスタンス全体のアクセス許可をまとめて管理するためには、ユーザーを適切な デフォルトのチーム に追加します。
ユーザー （これはデフォルトで、自動チーム割り当て により割り当てられます）。
査読者 （ 専門の査読者による review workflow を使用している場合）。
管理者 （管理操作の大部分を他のユーザーに委任する場合）。
すべてのプロジェクトを 公開 （参照: プロジェクトのアクセス制御）として設定してください。公開と設定されていない場合は、 ユーザー および 査読 チームの登録者に与えられたサイト全体のアクセス権は無効になります。
また、既定のチームに対して選択したアクセス権を追加できます。たとえば、すべての ユーザー にスクリーンショットを管理する権限を与えることができます。
新しいカスタム チームも定義できます。このチームの権限をサイト全体で管理するには、適切な値をプロジェクトの選択（すべてのプロジェクト または すべての公開プロジェクト など）で指定します。
言語、コンポーネント、またはプロジェクトの独自のアクセス権
独自の専用チームを作成して、言語、コンポーネント、プロジェクトなどの個別のオブジェクトのアクセス権を管理できます。これらのチームには、アクセス権を追加することしかできません。別のカスタム チームを追加して、サイト全体またはプロジェクトごとのチームにより付与されたアクセス権を取り消すことはできません。
例:
チェコ語 翻訳者専用のチームを追加する。
チェコ語翻訳者 グループ ロール
パワー ユーザー
プロジェクトの選択
すべての公開プロジェクト
言語の選択
設定を引き継ぐ
言語
チェコ語
アクセス権を付与したいユーザーを、このチームに追加する。
ご覧のとおり、この方法でのアクセス権の管理は強力ですが、非常に面倒な作業です。スーパーユーザーにアクセス権を付与しない限り、別のユーザーには委任できません。
ユーザー、ロール、チーム、およびアクセス権
認証モデルを構成するオブジェクト:
- アクセス権
Weblate に定義済みの個別アクセス権。アクセス権は、ユーザーに付与できません。アクセス権は、ロールを通じて付与します。
- ロール
ロールは、複数のアクセス権をまとめたものです。まとめたアクセス権は、複数の場所に再設定できるので、アクセス権の管理が簡単になります。
- ユーザー
ユーザーは複数のチームに所属できます。
- グループ
グループはロール、ユーザー、認証オブジェクト（プロジェクト、言語、コンポーネント リスト）を紐づけます。
注釈
チームには必ずしもロールを割り当てる必要はありません。誰もがプロジェクトを閲覧できる場合は、アクセス権の割り当ては必要ありません（下記参照）。
プロジェクトを閲覧するためのアクセス
ユーザーは、プロジェクト、またはプロジェクト内のコンポーネントにリンクされたチームに所属していることが必要です。所属していれば十分であり、プロジェクトを閲覧するための特定のアクセス権（これはデフォルトの 閲覧者 チームで使用されています。参照: チーム一覧）は必要ありません。
コンポーネントを閲覧するためのアクセス
アクセス制限のないコンポーネントでは、ユーザーは、そのコンポーネントのプロジェクトにアクセスできれば、コンポーネントにアクセスできます（そのプロジェクトに対してユーザーに付与されたアクセス権が、コンポーネントにもすべて適用されます）。アクセス制限 を有効にすると、コンポーネントへのアクセスには、そのコンポーネント（または、そのコンポーネントが含まれるコンポーネント リスト）に対して個別のアクセス権が必要になります。
チームの範囲
チーム内のロールが付与するアクセス権の範囲の規則:
チームに コンポーネント リスト が指定されている場合、そのチームのメンバーに付与されたすべてのアクセス権は、チームに登録したコンポーネント リスト内のすべてのコンポーネントに及びます。また、これらのコンポーネントを含むすべてのプロジェクトについては、新たにアクセス権を追加しなくてもアクセスが許可されます。コンポーネント および プロジェクト は無視されます。
チームに コンポーネント が指定されている場合、そのチームのメンバーに付与されたすべてのアクセス権は、チームに登録したすべてのコンポーネントに及びます。また、これらのコンポーネントを含むすべてのプロジェクトについては、新たにアクセス権を追加しなくてもアクセスが許可されます。プロジェクト は無視されます。
それ以外の場合、チームで プロジェクト を直接指定するか、プロジェクトの選択 から すべての公開プロジェクト などを選択することにより、アクセス権がそれらのプロジェクトに適用され、同じアクセス権がプロジェクト内の アクセス制限のないコンポーネント にも及びます。
チームの Languages による制限は、ユーザーが操確認実行するためのアクセス権があるか検証するときに行われます。つまり、査読、翻訳の保存、提案の追加など、翻訳作業に直接関係する操作にのみ適用されます。
ヒント
言語の選択 または プロジェクトの選択 を使用して、すべての言語またはプロジェクトを自動的に一括で設定できます。
例:
fooプロジェクトにはコンポーネントfoo/barおよびfoo/bazが含まれていて、次のチームがある場合:
スペイン語 査読管理者 グループ ロール
文字列の査読、リポジトリの管理
コンポーネント
foo/bar
言語
スペイン語
チームの登録者に与えられるアクセス権（既定のロール設定を前提とする）:
プロジェクト内のコンポーネント
foo/barおよびfoo/bazを含む、fooプロジェクト全体への一般的なアクセス（閲覧）。スペイン語訳（のみ）の
foo/barコンポーネントにある文字列の査読。
foo/barリポジトリ全体の VCS の管理。例: すべての言語の翻訳者によって行われた保留中の変更をコミットする。
自動チーム割り当て
Django 管理画面 の グループ 編集ページの下で、自動チーム割り当て を指定できます。これは、新規に作成したユーザーをメールアドレスに基づいてチームに自動的に割り当てるために使用する正規表現のリストです。この割り当ては、アカウントの作成時にのみ行われます。
この機能の最も一般的な使用例は、すべての新規ユーザーをデフォルトのチームに割り当てることです。そのためには、正規表現フィールドのデフォルト値（^.*$） をそのまま使用します。このオプションの別の使用例としては、デフォルトで会社の従業員に、アクセス権を追加で付与する場合です。従業員全員が、会社のドメインでメールアドレスを使用していると仮定した場合、^.*@mycompany.com のような正規表現で実現できます。
注釈
ある Weblate バージョンから別のバージョンにアップグレードすると、ユーザー と 閲覧者 へのチームの自動割り当てが常に再作成されます。これを無効にするには、正規表現を ^$ （何にも一致しない）に設定してください。
注釈
現在のところ、ユーザー画面から既存のユーザーをチームに一括で追加する方法はありません。一括で追加するには、REST API を使用してください。
デフォルトのチームとロール
インストール後、デフォルトのチーム セットが生成されます（参照: チーム一覧）。
このロールとチームは、インストール時に生成されます。組み込みのロールは、アップグレード時にはデータベースを移行して常に最新の状態に保たれます。実際に変更することはできませんが、独自のアクセス権のセットを設定したい場合は、新しいロールを作成してください。
アクセス権および組込みロールの一覧
対象範囲 |
アクセス権 |
ロール |
|---|---|---|
請求（参照: 請求） |
請求情報の表示 |
管理、請求 |
変更 |
変更点のダウンロード |
管理 |
コメント |
コメントの投稿 |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
コメントの削除 |
管理 |
|
コメントの解決 |
管理、査読 |
|
コンポーネント |
コンポーネント設定の編集 |
管理 |
コンポーネントのロック、翻訳の防止 |
管理 |
|
用語集 |
用語集への項目の追加 |
管理、用語集の管理、パワー ユーザー |
用語集の項目の編集 |
管理、用語集の管理、パワー ユーザー |
|
用語集の項目の削除 |
管理、用語集の管理、パワー ユーザー |
|
用語集の項目のアップロード |
管理、用語集の管理、パワー ユーザー |
|
自動提案 |
自動提案の使用 |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
翻訳メモリ |
翻訳メモリの編集 |
管理、翻訳メモリの管理 |
翻訳メモリの削除 |
管理、翻訳メモリの管理 |
|
プロジェクト |
プロジェクト設定の編集 |
管理 |
プロジェクトのアクセス管理 |
管理 |
|
レポート |
レポートのダウンロード |
管理 |
スクリーンショット |
スクリーンショットの追加 |
管理、スクリーンショットの管理 |
スクリーンショットの編集 |
管理、スクリーンショットの管理 |
|
スクリーンショットの削除 |
管理、スクリーンショットの管理 |
|
原文 |
原文情報の追加編集 |
管理, 原文の編集 |
文字列 |
新しい文字列の追加 |
管理 |
文字列の削除 |
管理 |
|
検査の不合格項目の除外 |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
|
文字列の編集 |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
|
文字列の査読 |
管理、査読 |
|
提案採用時の編集 |
管理、査読 |
|
原文の編集 |
管理、原文の編集、パワー ユーザー |
|
提案 |
提案の採用 |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
提案の追加 |
管理、原文の編集、提案の追加、パワー ユーザー、査読、翻訳 |
|
提案の削除 |
管理、パワー ユーザー |
|
提案に投票 |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
|
翻訳 |
翻訳用の言語の追加 |
管理、パワー ユーザー、言語の管理 |
自動翻訳の実行 |
管理、自動翻訳 |
|
既存の翻訳の削除 |
管理、言語の管理 |
|
翻訳ファイルのダウンロード |
管理、原文の編集、リポジトリへのアクセス、パワー ユーザー、査読、翻訳、言語の管理 |
|
翻訳用に複数言語の追加 |
管理、言語の管理 |
|
アップロード |
アップロードした翻訳の著者を指定 |
管理 |
アップロードでの既存文字列の上書き |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
|
翻訳のアップロード |
管理、原文の編集、パワー ユーザー、査読、翻訳 |
|
VCS |
内部リポジトリへのアクセス |
管理、リポジトリへのアクセス、パワー ユーザー、リポジトリの管理 |
内部リポジトリへの変更点のコミット |
文字列の査読、リポジトリの管理 |
|
内部リポジトリからの変更点のプッシュ |
文字列の査読、リポジトリの管理 |
|
内部リポジトリの変更点のリセット |
文字列の査読、リポジトリの管理 |
|
上流リポジトリの場所の表示 |
管理、リポジトリへのアクセス、パワー ユーザー、リポジトリの管理 |
|
内部リポジトリの更新 |
文字列の査読、リポジトリの管理 |
|
サイト全体の特権 |
管理画面の使用 |
|
新しいプロジェクトの追加 |
||
言語定義の追加 |
||
言語定義の管理 |
||
チームの管理 |
||
ユーザーの管理 |
||
ロールの管理 |
||
お知らせの管理 |
||
翻訳メモリの管理 |
||
機械翻訳の管理 |
||
コンポーネント リストの管理 |
注釈
サイト全体のアクセス権は、デフォルトのどのロールにも付与されません。これは強力で、スーパーユーザーの状態と変わりません。ほとんどのアクセス権は、インストールした Weblate のプロジェクトすべてに影響します。
チーム一覧
以下のチームは、インストール時（または setupgroups の実行後 ）に生成され、自由に変更できます。ただし、移行した場合、削除または名前が変更されていると、チームが再生成されます。
- ゲスト
未認証ユーザーのアクセス権の設定。
このチームには、匿名ユーザーのみ含める（参照:
ANONYMOUS_USER_NAME)。このチームからロールを削除して、未認証ユーザーの権限を制限できる。
デフォルトのロール: 提案の追加、 リポジトリへのアクセス
- 閲覧者
このロールにより、すべてのユーザーが公開プロジェクトを参照できる。デフォルトでは、すべてのユーザーがこのチームのメンバーである。
デフォルトでは、自動チーム割り当て と指定すると、新しい参加者には自動的にこのチームのメンバーのアカウントが作成されます。
デフォルトのロール: none
- ユーザー
すべてのユーザーのデフォルトのチーム。
デフォルトでは、自動チーム割り当て と指定すると、新しい参加者には自動的にこのチームのメンバーのアカウントが作成されます。
デフォルトのロール: Power user
- 査読者
査読者用のグループ（参照: 翻訳ワークフロー）。
デフォルトのロール: Review strings
- 管理者
管理者用のグループ。
デフォルトのロール: Administration
警告
想定外の問題が発生することあるので、デフォルトで設定済みの Weblate チームとユーザーは決して削除しないでください。これらの権限が不要な場合は、権限をすべて削除できます。
追加のアクセス制限
インストールした Weblate を、非公開で使用したい場合、つまり新規ユーザーを招待制でのみ許可するには、既知のユーザーのみがアクセスできるように Weblate を設定します。方法は、REGISTRATION_OPEN を False に設定して新規ユーザーの登録を禁止し、REQUIRE_LOGIN を /.* に設定して、すべてのサイト ページにアクセスするためにサインインを要求できます。これは、インストールした Weblate をロックする基本的な方法です。
ヒント
組み込まれた 新しいユーザーの招待 を使用して、新しいユーザーを追加できます。