[要望] 翻訳作業の流れについて

Local communities KDE 日本語フォーラム 🥷🍣
1

今はこんなフォーラムがあるんですね。メーリングリストだと過去に何の話がされたのか、探すのがかなり手間であったと思います。ありがとうございます。

さて、翻訳作業のワークフローに関して一つ提案があります。外部の翻訳支援サービス(CrowdinやTransifex等)を利用できないのでしょうか。

というのも、.poファイルは翻訳する側にとってはかなり手間がかかります。まず、テキストエディタ等で原文のまま作業するには向いていません。ソフトウェアは日本語の区切りを理解できずにダブルクォーテーション(")が文や単語の途中で挿入され改行されるため、特に他者がアプリ等を使用したものをさらに編集する場合は余計な手間がかかります。もちろん、fuzzyエントリの取り扱いも一律ではありません。HTML一つ触ったこともない方が多いでしょうから、プログラマが思っている以上に翻訳者の作業体験は悪いです。
二つ目、過去に翻訳された類似語や履歴、原文変更の表示、Google翻訳といった機械翻訳が利用できないために生産性が極端に落ちています。こうしたものを.po形式で利用できるアプリがあったとしても、有料だったりします。過去の翻訳をファイルの一番下に手作業でコメントアウトする扱いもされることがありますが、今やっている作業とどの程度一致してどこが違うのか、毎回探すのは現実的ではありません。また、翻訳したものは更新し続けなければいけませんが、結局どのエントリのどこが更新されたか(例えば、誤字1文字修正しただけなのか、内容全部書き直したのか)はリポジトリの履歴以外では全く分からないため、一度翻訳すると作業量が天文学的に増えていきます。
三つ目、メーリングリストを見ながら各人が競合を発生させないように作業し、メールに添付された成果物を一人のコミュニティメンバーが人力で処理するのは限界があると思います。翻訳者は翻訳中に原文が変更されても、他の人が作業していても全く分かりません。気分が乗れば1か月くらいかけて何万文字と訳したくなりますが、zip圧縮してメールで送らない限り一切適用されませんし誰にも分りません。

上に挙げたTransifexやCrowdinではオープンソースプロジェクトに使う限り無料です(この二つを挙げたのは自分が他のアプリ関係で使うことがあるからで、良いものがあれば何でも構いません)。以前の翻訳と重複していたり、2～3語程度で機械翻訳でも全く構わないものは、翻訳があっているか確認してクリックするだけで便利です。やり方によっては翻訳は全て保留状態にしておいて、言語のリーダー的存在が内容を確認した後にクリック一つで承認するということもできます。
こういうプロジェクトですから人的資源は圧倒的に限られています。せっかくオープンソースの活動に賛同いただいて有用なサービスを使わせて頂けるのですから、翻訳者が翻訳に集中できるように、こうしたものを活用するというのも一つの手ではないかと思います。

自分はKDEのやり方は良くわかりませんし、これはローカルではなく本家の方に言うべきだったかもしれません。明らかに変なこと言っているようでしたらスルーしてください。

1 Like
2

AlphaKodi さん、ご提案ありがとうございます。

残念ながら、こちらの KDE Discuss はまだ日本語コミュニティではあまり多くの人に使われているとは言えず、翻訳コーディネーターの人も見ていないと思います。
お手数なのですが、メーリングリストに投げて頂いた方が良いかと思います。この投稿の URL を貼って、メーリングリストから KDE Discuss に誘導する形でも良いかと思います。

本題の Crowdin や Transifex については、日本 KDE ユーザー会スタッフのみのクローズドなメーリングリストがあるのですが、そちらで一度話題に上がったことがあります。
ただ、翻訳コーディネーターの人からは「過去の kde-i18n-doc メーリングリスト (全言語の翻訳チームの ML) での議論からすると、そのようなサービスを使うことについては否定的な流れが強い」とのことでした。
オープンな場で議論した方が良いトピックであることもあり、その場ではあまり深く聞かなかったので、私の方では具体的な理由は聞いていませんが、必要に応じて翻訳コーディネーターの人に聞いてみるのも良いかもしれません。

今のところ考えられる課題としては、クローズとソースのツールの導入は難しい、というところでしょうか。KDE コミュニティにはフリーソフトウェア (無料ではなく自由ソフトウェアの方) の思想を持つ人も多いので、余程のことがない限り無理だと思います。
なので、Crowdin は厳しそうです。Transifex は、昔 (10年くらい前) はオープンソースだったような記憶があるのですが、今はクローズドソースになっていますかね?
Fedora Project などが使っている Weblate というのがあるので、こちらが候補としては良いかもしれません。

KDE もかなり長いプロジェクトなので、開発インフラがかなりレガシー化してきている印象があります。最近は結構改善されてきている印象ですが、翻訳関連に限ってはほとんど手がつけられていない印象です。確か今も Subversion 管理だったような…

なお、上記はあくまで KDE 全体での議論の話なので、もしかすると、日本語翻訳チームでのみ導入するというのは、まだ希望があるかもしれません。翻訳コーディネーターの人個人としてもあまりツールの導入には積極的でない印象もあったので、あまり楽観的なことは言えませんが…
日本語コミュニティ内でのみ使うなら、そこまで強いフリーソフトウェア思想の人はいない印象ですので、クローズドソースのツールでも大丈夫だと思います。

1 Like
3

phanect様、返信ありがとうございます。

一度は議論に上がっていたのですね。確かに、自由ソフトウェアの考え方からして、全員が納得いく形での導入が難しいというのは腑に落ちます。Weblateはその点においてかなり希望が持てそうですが、いずれにしても、やり方を変えるということ自体が、これまた手間のかかる一仕事であると思います。

ひとまず状況を知れたので、この話は一旦解決済みとさせていただきます。

1 Like
4

調べてみると、オンライン翻訳システムの導入について随分前からかなり白熱した議論がされているようです。これを見る限りでは、インターネットの使用によって諸々が遅くなり作業効率が悪くなることや、品質の担保の面から反対する向きが大きいみたいです。ただ、いくつかの言語チームではWeblateが使われている（使われていた？）ようです。

1 Like
5

インターネットというよりその板で例に挙げられているWeblateのレスポンスの悪さかな。Web GUIの読み込みが翻訳エントリごとに毎回1～3秒程度の待ち時間が発生するとか、KDEのような大きいプロジェクトには向かないとか。
序盤も終盤も、SVNからGitへの移行の話もされていますね。結局これ抜きには何もできない、「2020年にもなってSVNを使うのは、COBOLを使うようなものだ」と。

1 Like
6

インターネットのせいでというとメールの送受信もインターネットだろとなりますが、つまりそういうことですね。確かに、以前Weblateを使ったときにはレスポンスの遅さを感じました。MLではGNOMEで使われているDamned Liesも検討されているようです。ただそれについての議論はあまり進んでおらず、Weblateについては反対する意見が少なくないようで、少なくともKDE全体では導入されるとしてもそれはまだ先の話という印象があります。

1 Like
7

Weblate試せていないので何とも言えませんが、自分もナシかな。確かに次の翻訳が見えていないと、レスポンスの悪さ=何もすることのない無駄な待ち時間になるので結構ストレスになるだろうし、このUIだと前後の文脈を理解しにくくて訳の質は落ちると思う(ファイル名やソース/翻訳の日時を右側にデカデカと表示するスペースがあるならもっと有用なことに使って欲しい…)。

Transifexも入力できるようになるまでには1秒ちょいの遅延が発生しますが、前後のストリングが(それぞれ1行なら)計14くらい表示されていて、入力しなければいけないものを頭の中で考えることができるのでその点では快適ですね。これ以上バシバシ入力していくレベルだとオフラインアプリに軍配が上がりますが。

1 Like