さて、いくつかのケースがあります：
-
翻訳キーの変更: 避けるようにしていますが、時々それが不可能な場合もあります。英語の文字列が変更されていない場合は、翻訳メモリを使って既存の翻訳を自動的に再利用できます。Crowdin には「TM プリトランスレーション」というワークフローステップがあり、まさにそれを行います。
翻訳メモリ ™ を使用してファイルを事前翻訳し、同じまたは類似の文字列の翻訳を高速化します…
残念ながら、これにより翻訳者が後から翻訳を変更できなくなります。なぜなら、翻訳メモリによって翻訳された文字列は「クラウドソーシング」ワークフローステップを経られないからです。これは以前に報告しましたが、まだ修正されていないようです。そのため、現時点では「TM プリトランスレーション」を使用していません。cc @Andriy_Crowdin
-
変更された英語の文字列: どの程度の変更が「軽微」とみなされるのでしょうか？これは難しい判断であり、言語によっても異なる可能性があります。一歩引いて考えてみましょう。英語の既存の文字列を変更するとどうなるでしょうか？
- 変更された文字列を GitHub にプッシュします
- 翻訳者ボットがそれを取得し、Crowdin にプッシュします
- これにより Crowdin 上のその文字列のすべての翻訳が無効になりますが、Discourse 内の翻訳には影響しません
- 毎週火曜日、Crowdin から現在の翻訳を取得して GitHub にプッシュします
- 不足している翻訳は削除されます
- 新しい翻訳が追加されます
つまり、火曜日の直前に文字列を変更しない限り、Crowdin で新しい翻訳を提供する十分な時間があります。Crowdin 上の提案は、変更された文字列の翻訳を非常に簡単に行えるようにしています。
-
既存の翻訳に影響を与えないべき変更: 英語の文字列に対して軽微な一括変更を行う場合、通常は既存の翻訳を維持しようとします。例えば、過去に
{{count}}プレースホルダーを%{count}に変更した際や、英語のロケールの名称変更の際にそうしました。コミットメッセージに追加できる特別なコマンドがあります：@discourse-translator-bot keep_translations_and_approvals @discourse-translator-bot keep_translations
可能であれば、ワークフローの改善を実装する用意があります。ただし、Crowdin には「fuzzy 翻訳」という概念はありません。翻訳済みか未翻訳かのどちらかです。そして、それは良いことだと思います。そうでなければ単に複雑化してしまうからです。翻訳者としては、新しい文字列や変更された文字列について通知を受け取るので、これで翻訳者が状況を把握しやすくなるはずです。
@patrickemin 翻訳メモリから不足していたフランス語の翻訳を追加しました。これは今日の更新に含まれます。