こんにちは、フランス語版のDiscourseインストールにおいて、英語の文字列がフランス語に翻訳されていないものが徐々に増えているようですが、その理由をご存知でしょうか？ありがとうございます。
こんにちは、パトリックさん
これの翻訳はまだないと思います。ご自身で翻訳に貢献されたい場合は、翻訳について詳しくはこちらをご覧ください。
「いいね！」 2
実際、この文字列は以前の Discourse リリースでは多くの他の文字列と同様にフランス語でしたが、最新バージョンにアップグレードしてからはそうではなくなりました。
私はブラジルポルトガル語のインスタンスを運用していますが、同じように感じています。これについて最近のトピックがあり、そこで私の懸念を述べました。
https://meta.discourse.org/t/2-7-0-beta4-translation/181023/2?u=renato
ちょうど 例 を見つけました：
2021 年 2 月 12 日に、ボットが英語の文字列で「these」が「this」に変更されたため、古い翻訳を削除したことに注意してください。
理想的には、gettext のように変更が重要でない場合は古い翻訳を保持したいと考えています。間違った複数形でも、全体が英語のままになるよりはましです。
スクリーンショットの文字列についてさらに調査しましたが、その キー はコードのリファクタリングにより 名前が変更 されていました。これは例外だと思います。以前存在していた翻訳が不足しているケースの多くは、元のテキストの変更が原因だと推測します。
「いいね！」 6
@gerhard このオプションは検討されましたか？メールテンプレートなど、古い翻訳が致命的なケースもいくつかあることは承知していますが、一般的には、何もないよりは既存の翻訳から始める方がよいかもしれません。確信は持てません…ここには多くのニュアンスがあります。
「いいね！」 4
さて、いくつかのケースがあります：
-
翻訳キーの変更: 避けるようにしていますが、時々それが不可能な場合もあります。英語の文字列が変更されていない場合は、翻訳メモリを使って既存の翻訳を自動的に再利用できます。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 翻訳メモリから不足していたフランス語の翻訳を追加しました。これは今日の更新に含まれます。
「いいね！」 5
どこかで、gettext が類似性を測定するために Jaro 距離を計算する際のデフォルトの閾値を 0.85 としていると見たことがあります。完璧な解決策はないことは理解していますが、これらの変更を追うのが難しく、私は翻訳者ではなく、自分のインスタンスで欠落したテキストに気づいた時にのみお手伝いしているに過ぎません。それなのに、貢献が少ないせいで私の言語では「トップ」翻訳者となっています。
残念ながら、多くの言語で活動的な貢献者が不足しており、1 週間では新しい翻訳を完了するには不十分だと考えられます。Crowdin からメールが届くたびに確認するようにしていますが、私の言語ではすでに約 11,000 単語が不足しており、追いつくのが難しい状況です。
翻訳メモリ™ を使用してファイルを前翻訳し、同じまたは類似の文字列の翻訳を高速化します…
もし上記の修正が実装されれば、ワークフローが大幅に改善されるでしょう。また、これはあいまいな文字列のシナリオにも対応しているようです。
ユーザーがローカルで文字列をカスタマイズしている場合、どうなるのでしょうか？このケースではすでに問題になっていませんか？
別の代替案として、デフォルトでは無効化せず、意味全体が変更された場合のみ異なるワークフローを採用するという方法もあります。例えば、翻訳キーを変更するか、コミットメッセージに @discourse-translator-bot invalidate_translations を追加するなどです。これは、翻訳キーの意味を変更することが例外であるという前提に基づいています（これは完全に誤っている可能性もあります）。
とは言え、Crowdin は作業が非常にスムーズです。もしより多くの人が貢献していれば、これらの問題は発生しなかったでしょう。多くの人がテキストカスタマイズ機能を翻訳リソースとして利用していると考えています。
「いいね！」 1
そのことは認識しています。近い将来、いくつかの言語についてプロの翻訳者にご協力いただく可能性があります。ブラジル語もそのリストに含まれていると思います。
また、管理画面の「テキストのカスタマイズ」やデフォルトのロケール設定に、Crowdinへのリンクを追加することを検討しています。これにより、コミュニティの翻訳者の方々が正しい方向へ進む手助けになるかもしれません。
はい、その通りです。
「いいね！」 3