LibreOfficeの日本語UI/ヘルプの翻訳方法
LibreOfficeのUI/ヘルプの翻訳の日本語における手順を紹介します。
ごくごく基本的なルールは以下のとおりです。
- 標準で、どなたでも「訳の提案」はできる
- 訳の査読反映ができるのは、一部のメンバーのみ
- 提案後には原則メーリングリストで査読を依頼する
- 査読反映を行えるメンバーに昇格するには、継続的な貢献度を見て判断する
注:LibreOfficeの翻訳インフラは、6.4以降、pootleからWeblateへ移行されました(2019年秋)。Pootleを利用していた時代のガイドについては「LibreOfficeの日本語UI/ヘルプの翻訳方法(Pootle)」ページに残してありますが、歴史的な理由以外で参照する必要はありません。
LibreOfficeのUI/Help翻訳に関わる場合の注意点
前提として、2点ご注意いただきたい点があります。これらに同意いただいたうえで、翻訳活動にご協力いただきますようお願いします。
ライセンス
LibreOfficeのUI/Help翻訳は、LibreOffice自体と同様のライセンスに従う必要があります。Weblateに翻訳の提案(あるいは登録)を行うことで、その提案についてはMPLv2/LGPLv3+のどちらのライセンスでのリリースであることを認めたものとします。
機械翻訳の使用
UI/Helpに限らず、LibreOfficeの翻訳全般においては、機械翻訳の利用は行わないでください。
理由としては二つあります。
- 品質面
- 成果物のライセンス
品質面については、特にUI翻訳のように、文が短くて文脈に頼れない場合、機械翻訳は期待するような正しい結果を出さないことが多いです。 そうでなくても、敬体と常体の混合など見てわかるような誤訳だけでなく、用語の揺れ(長音記号の付与の有無など)、文章の一部の欠落など、一見すると日本語として通りがよい場合でも、不適切な訳文が得られることが残念ながらあります。
成果物のライセンスというのは、「ある機械翻訳サービスの翻訳結果をどのように扱ってよいか」という利用許諾が、前述のLibreOffice自体のライセンスや、その他のライセンスに抵触する可能性です。たとえば「商用利用不可」となっているサービスがあった場合、LibreOfficeに取り込まれた後にLibreOfficeをもとに商用ソフトウェアを作る権利(これはLibreOfficeのライセンスでは認められています)と衝突してしまいます。 このようなライセンスの衝突は後から検証することがとても困難ですので、原則、明示的に「これはオープンソースの一部として利用可能である」と宣言しているサービス以外は利用しないでください。
ただし、下訳として機械翻訳を使い、それをもとに品質・ライセンス面とも適合するように手直しして翻訳を行うこと自体は、もちろんかまいません。
メーリングリストの購読
LibreOffice の翻訳については discuss@ja.libreoffice.org にて話し合われています。また特定のアクションをとったときにはメーリングリストに報告する必要があります。 メーリングリストの解説ページを見て、購読してください。
Weblate にアカウントを作成
LibreOffice の日本語翻訳については Weblate で行っています。このサイトに必ずアカウントを作成してください。
登録を行なうことで、 VCS のコミット内に名前とメールアドレスが書き込まれるようになるほか、翻訳結果を各翻訳プロジェクトで規定されているライセンスで提供することになります。
Weblate 上で翻訳
アカウントを作成すると、誰でもすぐに「提案」ができるようになります。提案は権限がある誰かによってレビューされ「送信」を行うことで確定します。
セルフコミット
権限がある人は、下記のルールに従う形であればセルフコミットも可能です。
UI
- 新規の翻訳であればまず提案を行い、1日経過後に保存する。
- ひと目で見て分かる誤訳や簡単な修正であれば、提案を経ずに直接保存できる。
ヘルプ
- 翻訳は全て即座に保存できる。
- ヘルプ内のUIアイテム名や説明は、すべてUI翻訳におけるUIアイテムやツールチップ、詳細なヒントの訳に準拠する。
訳文の作成については、指針や留意事項などがいくらかあります。次のリンク先を参照ください。 (指針を改定したい場合はMLで議論を進めるようお願いします。)
なお、LibreOfficeの場合はmaster(最新開発版)と、安定版2バージョン (例えば2024.05.10時点では24.2と7.6) がアクティブなため、Weblate上でもそれぞれが翻訳可能になっています。
基本、新たな翻訳はmasterについていれこむことになっておりますが、ユーザーに混乱を招くような重大な翻訳誤りなどについては、過去のバージョンにも入れることになります。ここのところは明確な線引きはありませんので、よくわからない場合はMLで聞いてください。
UIの翻訳は字面だけではなかなか難しいものです (同じ単語でも文脈によって訳し分けが必要です)。「この用語はどこで使われているのだろう」と思った場合は、闇雲に作業せずMLやTelegramで相談しましょう。
今日のヒント(Tips of the Day)の翻訳について
Discuss MLより: https://listarchives.libreoffice.org/ja/discuss/2020/msg00134.html
今日のヒント(Tips of the day)は、得する情報をお知らせする機能なので、マニュアルのような硬い文章ではなく、フレンドリーでポジティブな文章になるように訳してください。
- 原文が問いかけ文になっているときは、崩さずに問いかけと答えの形で訳す
- 原文が「〇〇に困っていますか?」という形の文なら、一つの文にせず、そのままの形で訳します。
- 「してください」という丁寧な依頼の形は使わず「しましょう」と勧誘の形にする
- 操作の説明などは「○○してください」というお願いではなく「〇〇しましょう」と勧誘の形にします。
- 「することができます」は避ける
- 「〇〇することができます」ではなく「〇〇できます」として文をすっきり見せます。
discuss ML 上で提案提出の報告
どの翻訳に対して提案を行ったかは Weblate 上でわかりにくいため、ML で報告することになっています。 必須ではありませんが、「MLで報告したほうが査読が受けられやすい」ため、完全新規の翻訳以外であれば基本的に報告してください。
特に既存の翻訳を上書きする提案の場合、「どのような意図で提案を行ったか」を報告することが推奨されます。
また、訳語に悩んだりしたときにも ML で議論してください。
新規翻訳については必ずしも報告しなくても、リリースまでに査読される可能性は高いですし、量が多いので必須ではありません。ただし優先順位を上げたい場合、報告したほうが良いです。
権限を持っている人間が見落としていたりすっかり忘れている可能性もあるので、長く放置されている場合は催促してもらうほうがよいかもしれません。
MLへの報告テンプレート
基本的には、メールは適当に分割し「Writer どこどこの UI の翻訳」など、翻訳箇所がひと目でわかるようなタイトルにしてください。
表題:(提案したい内容をわかりやすく) ----- xxxです。下記の提案の査読をお願いします。 * Weblate URL: [URL(後述)] ... * どこで使われている用語か(わかれば): [そのUIを出すための操作など] * 提案の背景・理由: [特に既存の提案の場合、なぜ、新しい提案のほうがよいと思うのか、その理由] * Wikiへの記載内容: [LibreOffice日本語翻訳の変更点Wikiへの記載内容(後述)]
Weblate URLの取得
Weblateの画面にて、下図の赤丸の部分を右クリックしてURLを得ます。
Wikiへの記載内容
翻訳にあたり、既存の翻訳で不適切であったものを上書き修正する場合は、
https://wiki.documentfoundation.org/JA/Translation/Translation_fixes_<メジャーバージョン番号>
というWikiに変更内容を記載するルールになっています。 こちらのWikiはCategory:JA/日本語翻訳の変更履歴に一覧があります。
「提案」した時点では内容が反映されるかどうかはわかりませんので、査読反映した時点で査読した人間が記載するのですが、そこに書くべき内容をあらかじめ記載してください。
記載内容は簡潔に箇条書きにします。
* xxxによって表示される「△△」を「○○」に変更 ([変更者の名前])
操作方法について説明する場合、メニューの遷移を表現するにはbc
マクロが使えます。次のように使います。
入力例 | 表示例 |
{{bc|foo|bar}} | ▸ |
査読
TODO: 後で書く
Wikiへの追記
TODO: 後で書く
査読者リスト
ユーザー名 | 名前 | URL | 査読者化時期 | 備考 |
---|---|---|---|---|
baffclan | 日陰のコスモス | https://translations.documentfoundation.org/user/baffclan/ | 非アクティブ | |
naru0ga | Naruhiko Ogasawara | https://translations.documentfoundation.org/user/naru0ga/ | ||
nogajun | Jun Nogata | https://translations.documentfoundation.org/user/nogajun/ | 2020-05 | |
jm | jun meguro | https://translations.documentfoundation.org/user/jm/ | 2020-07 | 旧ユーザー名 parpy |
So | So Yanaihara | https://translations.documentfoundation.org/user/So/ | 2020-07 | 非アクティブ |
enoki | Shinji Enoki | https://translations.documentfoundation.org/user/enoki | 2021-10 | |
JO3EMC | JO3EMC | https://translations.documentfoundation.org/user/JO3EMC | 2021-10 | 非アクティブ |
翻訳の締め切りについて
(この項目はこのスレッドからの議論、主にこちらのメールを参考にしています。)
翻訳全体の流れをいうと(個々人の作業レベルではありません)、
- Weblateで翻訳する
当たり前ですが。ポイントは、翻訳したものがすぐにgitに入るわけではないということです。 - 翻訳の締め切りがくる
翻訳の締め切りは、LibreOffice グローバルの翻訳ガイドに書いてあるとおりタグを打つ2日前です。
タグを打つ日は、例えば4.2.0 beta2だとリリースプランにより12/2です。必ず月曜日です。ということは締め切りは12/1になるわけですが、時差の関係で(日本時間の)日曜日も使えます。よって、実質(日本時間の)日曜日が締め切りだと思ってください。 - 翻訳がgitに取り込まれる
- リリースタグが打たれる
(4.1.0 RC1以降月曜日にタグが打たれたことはない気もしますけど) - バイナリがビルドされる
ビルドできない場合はhotfixが入ります - リリース告知
リリース告知はミラーができていない段階(内向き)とミラー完了後(外向き)の2回あります
ということで、締め切られた翻訳が取り込まれるのは、そのタグが打たれたバージョンである、ということがわかります。
また、最後の RC (.0の場合は RC3 まで、それ以降はたいてい RC2 まで) は、ストッパーバグがなければそのままリリースされてしまうので、「あるバージョンに確実に入れたい」ということであればその一つ前を目標に定めるのがよいでしょう。