LibreOfficeのリリースノートを訳すときに考えること
LibreOffice 5.1リリースおめでとうございます！ パチパチ。
LibreOffice最新版 | LibreOffice - オフィススイートのルネサンス
ここからダウンロードできるようになってます。まだ出たばっかりなので「好き者」*1 以外には推奨しませんが、新しいUIとか細かいところが使いやすくなってるし、結構いいんじゃないかなって思います。
で、新バージョンが出たら当然、リリースノートぐらいは日本語になってて欲しいと思うので、しばらくはこの作業をしてました。
今回はすでに大部分が訳してあったので、私はぶつくさ言いながら気に入らない翻訳を直しただけなんですけど。たとえ原型をとどめないほど直したとしても、誰かの訳した日本語を手掛かりにする方が、ゼロから英語訳すよりかはずっと楽なので、感謝感謝であります。4.4ぐらいまではほとんど自分一人で訳してたからなあ。
そんなわけで今回は、私がリリース通知のようなものを訳すときに考えることを思いつくまま列挙してみようと思います。LibreOfficeに限らず、コミュニティでメンテされているリリースノートの類の翻訳に参加してみようかなと思う方の参考になれば幸い。
なお、お断りですが、私は決して英語得意ではないですし（むしろ苦手だし嫌い）、往々にして、日本語として通りが良くなることを優先して原文の構造をがつっと無視することもあります（もちろん、そうやって作った日本語が、正しく意味を反映していると自分は信じていますけれども）。
UIを調べる
リリース通知なので、「こういう機能が追加されたよ」ということがほとんどなわけです。追加された機能にはUIがあって、UIはたいてい翻訳されています（というか、されてないと困る）。
であれば、UIの翻訳がどうなっているかを調べ、それに用語を合わせるのは、まあ最低やって欲しいところではありますね。
もしUIの翻訳を調べるのが難しい（ギリギリに翻訳されたので手元の開発版だとまだ英語、どうやってUIを出すかわからない、エトセトラエトセトラ）場合は、無理に日本語をでっち上げないで、英語のままにしておいてもらう方が、むしろありがたいですね。
定訳を調べる
定訳というほど立派なもんじゃないですが、例えば locale は「ロケール」だとかいうのは、過去のリリース通知を見ればわかるので、それは押さえてほしいなあ……と。
リリースノート的な言い回しを考える
例えば：
The spell-check dictionary now contains over 250,000 words. The new version adds over 20,000 new words.
という文があったとき、"now" を「今」とか「現在」とかに 訳したらダメ です。
リリース通知で「now」と言ったら、「前のバージョンでは違ったけど、このバージョンでは」という意味だと考えてほぼ間違いありません。なので、「……になりました」というのがおきまりの訳し方ですかね。
同様に「The new version」も、今まさにリリースノートで説明しているバージョン（あるいは、それに同梱されている何かのコンポーネントのバージョン）に決まっているので、「新しいバージョン」とはしない方がいいですね。
なお、参考までに現在の訳はこう。
スペルチェック辞書には250,000を超える単語が収録されています。20,000以上の単語が追加されました。
なんで第一文が「収録されるようになりました」とかではないかというと、続く文で「追加されました」と言ってるので、2万語以上追加されて結果25万単語になったというのは見ればわかるからです。
あとこれはリリースノートっぽいというより英語と日本語の違いですけど、例えば：
Right clicking a slide now supports saving a background image to file, this matches the pre-existing set background image option.
みたいな文は：
スライドを右クリックすることは背景画像をファイルにセーブすることをサポートします。
と「すること」を主語として残すと非常に直訳くさくなるので、
スライドを右クリックして背景画像をファイルに保存することが可能になりました。
みたいにするといいですね。
ここで偉そーに講釈たれるほどいろんな引き出しを持ってるわけではないですが、「now supports」は「……できるようになりました」はありがちかなあ、とか、なんとなく定型パターンを持っておくと楽になりますね。
文体は統一する
目先の翻訳に一生懸命になりすぎるからでしょうかね、敬体（ですます）と常体（だ、である）が混じった翻訳になっちゃうのは。こういうのは読み手の印象を著しく下げるので、翻訳終わった後すぐにsubmitせずに、一息入れて読み返してから入れていただけるといいかなーと思います。
なおLibOのリリースノートは基本、敬体ですけど、（パッと例は思いつかないですが）文の構造によっては常体や体言止めになることもあり得ると思います。箇条書きなんかだとあり得るかな。そこはルールというより、読み手にとって読みやすければいいかなと。
ある程度は調べる
実際に動くバージョン（開発版）を手元にインストールして、動きを試してみる。
MS Officeとの相互運用に関する変更なら、MS Officeのドキュメントを検索して調べる。
不具合修正の場合は、たいていBugzillaへのリンクがあるはずなので、そのバグ票を読む。
新機能については開発者がブログ記事を書いていることもあるので、そのリンクが書いてある場合は読む。
せっかく手掛かりになる情報を開発者が書いてくれてるのであれば、それを参考にして、訳文を作る手掛かりにしましょう。
調べてもわからないところは無理に訳さない
まあ、当たり前のことです。 メーリングリストとかで「ここはわからないんで誰かよろしく」って聞くのがいいんじゃないでしょうか。
個人的考えでは、UNO API周りとかコアの性能改善周りとかは、わからないなりな日本語になっているより英語のままの方が望ましいと思います（もちろん、質が確保できるなら日本語になってる方が良いに決まっていますが）。特にプログラミング系の説明は、知ってるか知らないかで全然違いますからね。
その他細かいこと
A, B and Cは「A、B、およびC」ってするといかにもThe直訳って感じするので、「AおよびB、C」と書き直したり、あるいは文脈より明らかなら「A、B、C」にするとか。
リリースノートにはその変更を行った人のクレジットが入ってるんですが、(XXX and YYY）は、（XXX、YYY）にするとか。
ここでカンマを使ってしまうと(XXX, company name) という表記とぶつかるので読点にするとか。
リリースノートを書いてるみんながみんな英語ネイティブではないので時々構文壊れてたりしますので、どうにも意味が取れない場合は原文の間違いを疑うとか。
細かいことを言い出すときりがないんですけどね。
終わりに
私がリリースノートの翻訳するときに考えてることをつらつら書いたら、なんかめっちゃ長くなってしまった。
UIの翻訳に比べるとリリースノートの翻訳はちゃんと文になってるので、「これってどこで使われてるの？どういう文脈？」みたいな悩みは少ないですが、その代わり、「出来上がりがちゃんと日本語になっているか」みたいなところを気にする必要があるので、どっちが簡単とか難しいとかではなく、違う種類の作業だなと感じます。
あーでも、あんまり萎縮しないでくださいね。要はみんなの手が入ることで、最終成果物が良くなってればいいので。
翻訳挑戦してみたいなー、でもいきなり反映するのは怖いなー、という方は、LibreOfficeのリリースノートはWikipediaと同じmediawikiを使っていて、ユーザーページと言うのが作れるので、その下に訳文作って「見てもらえますかー？」とメーリングリストに問いかけるってのもいい手だと思います。
あと私自身は今のところ使えてないのですけど、OmegaTみたいな翻訳メモリー機能を持つ翻訳支援ソフトウェアを使った共同作業ができたらいいかもなーとか考えてます。他の言語コミュニティだとUIとドキュメント共通の翻訳メモリを使ってるところもあるみたいですが、それは今のところ懐疑的なんですよね。でもリリースノートに関しては、使えるかもって思ってる。ここらへん、一緒になってプロセス考えてくれる人募集中です。
長くなっちゃった。では！
*1:多少不安定でもいい！新しい機能をすぐ試したい！って人とか、不具合を踏んだらバグ報告して直してもらえる可能性がある！嬉しい！というマゾさん、という意味。ちなみに私は両方です。
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……こんな記事を書いてないで、翻訳を進めればいいのにね＞じぶん
ま、そんな感じでやってますということで。参考にでもなれば幸い。
LibreOfficeをコマンドラインで使うと便利だよ
LibreOffice Advent Calendar 2015 21日目。本日も超小ネタ。
みんな知ってるのかなーと思ったのですが、意外と知らない人がいるようなので*1。
LibreOfficeのいろんな機能は実はコマンドラインから起動できます。
Ubuntu*2の場合は実行パスが通っているので、単純に実行できます。
$ soffice --help
LibreOffice 5.0.2.2 00m0(Build:2)
Usage: soffice [options] [documents...]
Options:
--minimized keep startup bitmap minimized.
--invisible no startup screen, no default document and no UI.
--norestore suppress restart/restore after fatal errors.
--quickstart starts the quickstart service
--nologo don't show startup screen.
--nolockcheck don't check for remote instances using the installation
--nodefault don't start with an empty document
--headless like invisible but no user interaction at all.
--help/-h/-? show this message and exit.
--version display the version information.
--writer create new text document.
--calc create new spreadsheet document.
--draw create new drawing.
--impress create new presentation.
--base create new database.
--math create new formula.
--global create new global document.
--web create new HTML document.
-o open documents regardless whether they are templates or not.
-n always open documents as new files (use as template).
--display <display>
Specify X-Display to use in Unix/X11 versions.
-p <documents...>
print the specified documents on the default printer.
--pt <printer> <documents...>
print the specified documents on the specified printer.
--view <documents...>
open the specified documents in viewer-(readonly-)mode.
--show <presentation>
open the specified presentation and start it immediately
--accept=<accept-string>
Specify an UNO connect-string to create an UNO acceptor through which
other programs can connect to access the API
--unaccept=<accept-string>
Close an acceptor that was created with --accept=<accept-string>
Use --unnaccept=all to close all open acceptors
--infilter=<filter>[:filter_options]
Force an input filter type if possible
Eg. --infilter="Calc Office Open XML"
--infilter="Text (encoded):UTF8,LF,,,"
--convert-to output_file_extension[:output_filter_name[:output_filter_options]] [--outdir output_dir] files
Batch convert files (implies --headless).
If --outdir is not specified then current working dir is used as output_dir.
Eg. --convert-to pdf *.doc
--convert-to pdf:writer_pdf_Export --outdir /home/user *.doc
--convert-to "html:XHTML Writer File:UTF8" *.doc
--convert-to "txt:Text (encoded):UTF8" *.doc
--print-to-file [-printer-name printer_name] [--outdir output_dir] files
Batch print files to file.
If --outdir is not specified then current working dir is used as output_dir.
Eg. --print-to-file *.doc
--print-to-file --printer-name nasty_lowres_printer --outdir /home/user *.doc
--cat files
Dump text content of the files to console
Eg. --cat *.odt
--pidfile file
Store soffice.bin pid to file.
-env:<VAR>[=<VALUE>]
Set a bootstrap variable.
Eg. -env:UserInstallation=file:///tmp/test to set a non-default user profile path.
Remaining arguments will be treated as filenames or URLs of documents to open
詳しくは個別に見ていただくとして、 --headless に注目。これを使うと、LibreOfficeのGUIを表示せずに機能を利用できます。ありがちなのは：
soffice --headless --convert-to pdf:writer_pdf_Export *.doc
とか。これでカレントディレクトリにある *.doc ファイルをガツンとPDFに変換できます。サーバーサイドに置いておいて、適当なファイルがアップロードされたらPDFに変換、みたいなサービスを提供するのに使えますね。
なお --headless オプションは、他にLibreOfficeが上がっている場合は何も言わずに終了してしまうのでご注意。
なおOS Xの場合は：
/Applications/LibreOffice.app/Contents/MacOS/soffice
を叩いてください。
Windowsは手元にないのでわかりませんが、32bit版は c:\Program Files(x86) 以下、64bit版は c:\Program Files 以下のLibreOfficeのフォルダ以下に program というフォルダがあって、そこに soffice.exe という実行ファイルがあるのでこれを叩きましょう。バッチファイルを書いておくといいかも。
--infilterや--convert-toのフィルター指定にはいろいろオプション指定も効くので、これについての情報もお知らせしたいところですが、情報源がないのでまた今度。すみません！
追記：このネタ、「LibreOffice コマンドライン」とかでググるとたくさん出てくるので、今更感もありますけど、Advent Calendarにぶら下がってる方が見つかりやすいよね、という言い訳。
*1:秋のOSC東京で紹介したら、すごい感激された。
*2:しか手元にないけど、他のLinuxディストリビューションでも同じなのだと思います。
LibreOfficeのハイブリッドPDF機能とSlideShareを組み合わせると便利
LibreOffice Advent Calendar 201518日目。今日も小ネタです。
LibreOfficeのPDFエクスポート機能には「ハイブリッドPDF」という機能があります。
ファイル ▶︎ PDFとしてエクスポート、の「全般」タブにある「ハイブリットPDF（ODFファイルを埋めこむ）」というチェックボックスです。
PDFにはその仕様上、お好きなデータを埋め込むことができるんですが（雑な説明です）、その機能を利用して、編集元のODFファイルをPDFの中に埋め込むことによって、「PDFビューアーで開いた場合にはPDFとして、LibreOfficeで開いたときには編集可能な文書として」扱えるというものです。この機能は結構昔から存在しているので、便利に使っている人も多いでしょう。
ところで、どこかで発表したスライドを公開するのに、SlideShareやSpeakerDeckといったサイトを利用している人も多いと思います。 私は昔アカウントを作ったという消極的な理由でSlideShareを使っていますが（あと、SpeakerDeckは検索がほぼ使い物にならないのが気に入らない）、SlideShareはODFファイルでのアップロードも受け付けてはいるんですが、フォントが足りてないのか何なのか、レンダリングがぶっ壊れて悲しくなるんですよね。 なので、アップロードはPDFで行うことが多いです。これならレイアウトも綺麗に（意図した通りに）でます。フォント埋め込みもバッチリです。 アニメーションやスライド切り替えの効果は落ちてしまうのですが、普段からあまり使っていませんし、アニメーションは最初からスライド切り替えでパラパラ漫画で実現することが多いので、これもあんまり困っていません。
さておき。 アップロードする時のPDFを、前述のハイブリッドPDFにしておくと、SlideShareの「スライドのダウンロード」機能で取ってこれるスライドもハイブリッドPDFになる、ということはご存知でしたか*1？
例えば、先日開催されたUbuntu 15.10リリース記念 オフラインミーティング 15.12の私の発表資料。
ここに行って、ダウンロードボタンをぽちと押して：
ダウンロードすると*2 PDFが落ちてきます。
これをダブルクリックで開くと当然PDFとして開くわけですが、LibreOfficeから、ファイル▶︎開く、で開くと、ちゃんとImpressのドキュメントとして開けます。
わかりにくいですがファイル名に注目。PDF文書なのにImpressでオープンされています。
なお埋め込みPDFじゃないPDFもLibreOfficeで開くことができますが、インポート扱いになってしまい画像が乱れたりなんだりするので、こうやってそのままさっと編集できるのは嬉しいですね。
私の場合、スライドはクリエイティブ コモンズ 表示-継承 (CC BY-SA) で公開していますので、同じCC BY-SAライセンスのスライドであれば、スライドの出展を明らかにしてくだされば、適当にダウンロードしていただいてスライドを改変再利用いただけます。是非是非、使ってみてください。
またCCのような改変再配布を許すライセンスを明記してSlideShareを使う場合、埋め込みPDFを使うというのは割と良い手だと思います。ちょっとサイズが膨らむという欠点はありますけれども。
明日はrakugouさんですね。宜しくお願いします！
Ubuntu WilyのシステムPython3でLibreOfficeをコントロール
LibreOffice Advent Calendar 2015 17日目というか、Facebookの書き込みを見て、あれ、Ubuntuの場合はシステムPythonでPyUno（PythonからLibreOfficeの外部インタフェースUNOを使えるようにしたバインディング）使えたんじゃなかったっけと思って試してみました、というだけの話。
私Pythonとか5行ぐらいしか書いたことないので（ややうそ）、勘違いとかあったら教えてください。
せっかくなので、ちょっとググっていたら見つかった、PyUNOをより簡単に使えるようにしたラッパーライブラリであるunotoolsを試してみます。
まずは必要そうなパッケージをaptでガツガツとインストール*1。すでに入ってるものもあるかもだけど気にしない。
$ sudo apt install libreoffice-script-provider-python python3 python3-uno
これでpython3からPyUNOが呼べることをまず確認します。
$ python3 Python 3.4.3+ (default, Oct 14 2015, 16:03:50) [GCC 5.2.1 20151010] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>>
問題なさげですね。
次にunotoolsですが、こいつはpipなライブラリなのでまずはpipを入れねばならんのです。apt searchするとpython3-pipというのがいるので、こいつだ！と思ったのですが、どうも罠っぽい。
あるべき姿がわからんのですが、調べるのもめんどくさいのでsetuptoolsを経由して入れてしまいます。virtualenvとか使う方がいいんだろうなーとか思いつつ。
$ sudo apt install python3-setuptools $ sudo eazy_install3 pip $ sudo pip install unotools
これで入ったっぽい。
ではunotools公式サイトの例題をやってみます。
最初にLibreOfficeをポート指定して起動。
soffice --accept='socket,host=localhost,port=8100;urp;StarOffice.Service'
それからpython3を起動し、パッケージをインポートしてコネクションを張り、Writerのインスタンスを起こす。
$ python3
Python 3.4.3+ (default, Oct 14 2015, 16:03:50)
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from unotools import Socket, connect
>>> from unotools.component.writer import Writer
>>> context = connect(Socket('localhost', 8100))
>>> writer = Writer(context)
で、起こしたWriterインスタンスに対して、「文字列を文章末に追加」する。
>>> writer.set_string_to_end('Hello\n')
>>> writer.set_string_to_end('World\n')
はい、こんな感じでWriterにPythonから出力することができました。
例のための例で恐縮ですが、unotools良さそうですね。
なお、本家PyUNOも、次期リリースの5.1では「もっとPythonらしいインタフェース」になるというお話が今年のLibreOffice Conferenceでありました。興味がある方は是非発表資料(PDF)をご覧あれ。
明日は誰か書いてくれるかな？それでは！
*1:最近、可能な限りaptコマンドで生きようと思っております。
関東LibreOffice忘年会2015を開催してきた
LibreOffice Advent Calendar 2015 15日目です。なんだかんだで途切れずに来ていて嬉しい限り。
さておき。
すっかりサボっている関東LibreOfficeオフラインミーティング。
最近気力体力ともに衰えていて、LibreOfficeについても「これはなんとかしたい」と思ってることがぜんぜんできてなくて、オフやるのもしんどいし、手伝ってくれる人はいないし、やらないの？って声もないし、じゃあいいかーとサボってたのですが。
まあ忘年会ぐらいはやったほうがいいな、ということで、急遽声をかけたら5人集まりました。嬉しいな。
せっかくなのでなんか話するかということでこんな話をしました。
来年は、1/9のminiconfがおわってから考えますが、多分翻訳スプリントとかやるんじゃないかな、と思います。5.1.0の翻訳締め切りは1月なので。
その先は未定ですが、運営に関わってもいいよって人、なんか喋らせろって人、関東と言いつつ東京以外でやってないのはけしからん、俺の地元でやるから来いって人、ぜひ連絡ください。お待ちしてます。
LibreOfficeの質問をメーリングリスト以外にするには（Ask.LibreOffice.orgのご紹介）
今日はスーパー小ネタ。
先日はNabbleフォーラムを用いたメーリングリストの投稿の仕方を説明しましたが、今日はそれ以外にLibreOfficeで質問をしたい場合はどこを使えばいいかという話を超カンタンにします。
Ask.LibreOffice.org
というサイトを皆さんご存知でしょうか？
これは、知っている人は知っている（技術系の人はご存じの方が多いかな？）StackOverflowとかに近い質問投稿サイトです。AskBotとか呼ばれます。
このサイトのポイントは：
- 投稿した質問に情報が足りなかった場合、あとから質問自体を編集できる。これによって「後から同じ問題にハマった人にも役立つ、よりよいQ&A」を作れる
- 質問や回答に対してプラスやマイナスの投票をユーザーがすることができ、有益なやりとりだったかどうかを判断できる
- 「この回答で解決したよ」という回答にチェックを付けられる
ので、使うときには「単なる質疑応答」ではなくて、「よりよいQ&Aを作るんだよ」ということを意識してもらえるとうれしいです。
あまり知られていないのかまだまだ質問・回答共に少ないので、みんな使ってもらえるとうれしいです。
今日はスーパー小ネタなので使い方とかは次回に譲ります。すみません。すみません。
