LibreOffice翻訳査読者としての自分の基準
ついったに書いたのをまとめておきます。
これはあくまでも私はこうしている、というだけの話で、LibreOffice日本語翻訳コミュニティの総意でもなければ、査読をするならばこういう風にしなさい、という意味でもないです。
ぼくがLibOの翻訳査読をするときのざっくりした方針。1)割と作業者で見てる。字面で正しいと思ったらOKにする提案者と、実際のUIでの使われ方や過去翻訳との突き合わせまでする提案者は明確に区別されてる
— Naruhiko Ogasawara (@naru0ga) 2016, 1月 30ちょっと補足必要かな。 もちろん、査読者として「この翻訳は妥当かどうか」をチェックする責任はあります。
ただ、UIの翻訳というのは、やってみれば分かるんですが、「英語を見て日本語を見て、対応があっていればOK」とはいえないところに難しさがあるのですよね。 極端な例を上げれば、「Line」という単語だけで「行」なのか「線」なのかを知ることはできなくて、それがどこで使われてるかをチェックする必要がある。 「Property」という単語が「プロパティ」なのか「属性」なのかは、同じ文脈の既存の翻訳がどうなのかを調べて併せる必要がある。
で、そういうチェックをやってから提案を上げてくださる方と、そうでない方というのはやっぱりいるのです。それは査読してれば分かるのです。ので、査読者の私としては「あ、この人なら大丈夫だな」と思う人については、字面のチェックだけで通しちゃうことがままあるということ。褒められた話ではないけど、未翻訳のまま放置されるよりはいいでしょうと。
お断りしておきたいのは、そういうチェックをしなきゃダメということではなく、例えば統計とか財務とかの専門性が高い用語については、そういうことは後回しで分かる人がとにかく訳してくだされば、あとからチェックはできるんでいいんですよ。だから査読ってシステムがあるわけで。そゆ意味で、萎縮はしないでくださいね。
さて次。
2)新規翻訳については、悩んだら入れてる。特にRC期間の間は。入れてみて反応を見て、ダメだったら変えればいい、タイムベースリリースとはそういうもの、という割り切りをするようになった
— Naruhiko Ogasawara (@naru0ga) 2016, 1月 30これはあんまり説明の必要はないですね。昔はけっこう悩んで、自信がない奴は入れないって態度だったんだけど、それはタイムベースリリースの利点を生かしてなくて、査読者としてはよくない態度だ、的な注意をうけて、それから新規翻訳については大胆になることにしました。
3)既存翻訳の修正提案について。査読者のぼくは相当にコンサバ。既存翻訳よりも良い表現になっているなあというレベルだとまず入れない。「なぜこうしたか」という表明がMLでされていれば別。明らかな誤訳なら直すけど。なお「明らか」の基準は自分の中にしかないのですまぬ
— Naruhiko Ogasawara (@naru0ga) 2016, 1月 30これはやはり、「一度定着した語を変えるというのは、昔のユーザーに変化を強いることになるので、それなりに慎重に決めたい」と思うからです。そしてLibreOffice日本語翻訳の議論の場はMLなので、MLで「こういう風にしたほうがよい」というコンセンサスがなければ、私はその査読を（個人としては新しい提案のほうが確かにいいな、理にかなってるな、と思っても）取り込むことはないですね。
ただ、ここで「うーん、いい感じだけど、説明がないから、今は入れない」と決めた奴を、提案そのままにして残しておくと、「新規の提案を虱潰しに査読する」フェーズのときに邪魔になるんですよねえ。でも議論することなく破棄しちゃうともったいないなーと思って捨てられない。悩ましい。
年単位で保留されてる奴は、MLで棚卸して提案者からコメントがない限り破棄、みたいなことやったほうがいいのかなあ。
最後は、これはついで。まあ当たり前といえば当たり前。
4)ちょっと話題がずれるんだけど、査読者はセルフコミットできるんですが原則はダメ。でも、アクセラレータの抜けとか末尾...の抜けとかは勝手に直しちゃってる。あと、新規翻訳を提案して2週間ぐらい放置された場合もいれちゃってます。これはさっきの「入れて様子見」戦略
— Naruhiko Ogasawara (@naru0ga) 2016, 1月 30……こんな記事を書いてないで、翻訳を進めればいいのにね＞じぶん
ま、そんな感じでやってますということで。参考にでもなれば幸い。
