おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

チェコ入院の記録など

misc

ご無沙汰さんです。

ご存じの方はご存知ですが、今年も夏休みを取ってLibreOffice Conference 2016参加のためにチェコに行ってきました。 そして、行きの飛行機の中で発病して、到着した翌々日には病院に行き、その場で入院となって、三泊四日の入院生活を過ごして帰ってきました。

入院は9/7で退院は9/10、その足で鉄道と飛行機で9/11夜に日本に帰ってきて、9/12に病院に行って安静を命じられ、会社を3日追加で休んでお家でヒマヒマしてました。今はまあ、ちょっとまだ完全ではないですが、大分良くなりました。普通に歩けますし仕事もできます。

そんな内容を、9/17の小江戸らぐ #koedolug で発表してきたらまあまあ好評？だったので、せっかくだからまとめることにしました。発表資料はこちら↓。

といっても発表資料に概ね書いてしまったので、まあ雑多な落穂ひろい。あとめっちゃ長いので、お時間がない方は上の資料だけを読むことを推奨。

続きを読む

OSS Gateワークショップ#2にメンターとして参加しました

OpenSource Event

随分時間が経ってしまいましたが。

3月26日に行われたOSS Gateワークショップ#2というイベントにメンターとして参加してきました*1。

oss-gate.doorkeeper.jp

OSS Gateの素晴らしいところは、その目指す姿とか行動指針とか実際の進め方とか（好きなようにやってもいいよっていうと初めての人は却って困るので、むしろやり方をがちっと限定するとか）が決まってて、それがオープンになってて、かつ意見を吸い上げて改善していこうというもので、そういう話について私がここであーだこーだ書くより、サイトとかGithubのプロジェクトページ：

github.com

特にシナリオを読んでもらったほうがいいと思うので省略。

ここではメンターとしての私がどう行動したか、なにを感じたかの話をメモしておきます。

アドバイスしたこと

  • 日本語のドキュメントを読んで？？となったときには英語のドキュメントも見てみよう
  • 何かやってみたいなってときにはcontributionってドキュメントにやりかたがないか探してみよう
  • 過去の人のやり方を真似よう（Issue登録とかPull-reqとか）
  • 一つのissue登録やpull-reqは小さな単位（一つのことしかいわない）にしよう

自分はアドバイスしなくて、アドバイスを聞いておおーって思ったこと

  • 会社マシンでgit使うときにはglobal configに汚染？されないように気をつけよう

  • ドキュメントは別のプロジェクトになってることがあるので、念の為確認しよう

取り回しで感心したこと

  • 悩んだり詰まったりしたときはメモだけさせてどう直したら良いかは後で考える。とにかく先に進む。

あえてアドバイスしなかったこと

  • コミットコメントやプルリクエストの英語。「自分ならこうは書かない」とか「経験的にこうしたほうが反応をもらいやすい」とかあったんだけど、ぐっと飲み込んだ。自分の持ってる英語力で作文してみて、それが通じたよ、って体験の方がずっと大事だと思ったから。結果的には正解だったと思う。

次回は5/28だそうです。Rubykaigiの裏番。

oss-gate.doorkeeper.jp

メンタリングを受けたい人、メンターやってみたい人、自分とOSSの関係を問い直したい人とかも参加するといいんじゃないかと思います。メンター側に興味がある人は、OSS GateのGitter oss-gate/general - Gitter に参加するのがよろしいかと。

私自身は、次回はちょっと悩み中……。

*1:まったくどうでもいいけどこの日は私の誕生日でした。

関東LibreOfficeオフラインミーティング ネタ帳

LibreOffice Event

ども。あ、ブログのテーマ変えました。なんでお寿司にしたんだっけ……みたいな。こういう地味なテーマのほうが好き。

さておき。

私が発起人になっている関東LibreOfficeオフラインミーティングというイベントがあります。あ、私発起人であって幹事ではありませぬ。そこんとこよろしく。

Twitterでちょっと話題になってた、「IT系勉強会に来る変な人問題」に絡んで、「勉強会ってあんまり勉強にはならないよね」という、勉強会ムーブメントがすごい盛んだったときに100万回ぐらい聞いた文字列*1 を読んだので、

と書いた。

まあ、自嘲っぽいのは私の性格なんで置くとして。

勉強会（と世の中で呼ばれているもの）に私自身が参加したいというインセンティブは、「勉強」したいわけじゃなくて、ブログとかTwitterとかメディアの中で面白いことを言ってるしてる発表してる人と出会って面白い話を聞くことであって、要はオフ会ですよね、それって。オフ会であるならば勉強になったかならないかではなく、楽しかったか楽しくなかったかで参加した価値を判断すればよいのでは。うん、個人的にはそうしよう。

であれば、自分が発起人であるイベントは、どうどうとオフ会を名乗ろう、とか思ったという話は、何度となくしております。

じゃあその「オフ会」で、できるできないはさておき、どんなネタを取り上げてみたいのか、というのを列挙したので、こっちにもコピーしておきます。

ということで色々やりたいです。賛同してくれる人なんかコメントなり何なりどっかでください。

PS.

これはどうでもいいんだけど、「関東LibOオフ」なのに「LibOKanto」だと逆なのと、とある人名に空目するって指摘を複数人からいただいているので(^^;

*1:本題じゃないですが、こういう言説についてのぼくの立場を書いておくと、セミナースタイルの勉強会で受講側になって勉強できることなんて限られてるのは同意。ただ、「あ、この技術は注目すべきなんだな」「自分で学ぶにはここらへんのキーワードを追っていけばいいんだな」というネタを拾える場としてはいいと思う。そこから先は自分で手を動かして頭を使わないと勉強にはならないよね。多分。逆にいえば他の手段でネタを拾える人はセミナー型の勉強会で聴講なんかしてもあんまおもしろくないのかなとは思います。あと、登壇側になるといろいろ調べるので勉強になりますね。

Frisbyで「リクエストを投げたサービスが突然死した」ことを検知できるか（小ネタ）

Test

ちょっと仕事で調べたのでメモっとく。私HTTPとかあんま詳しくない*1 ので間違いあるかも。

ちょっとしたWeb APIのテストを書いてます。というか、書くために調べ始めました。APIといってもGETでリクエスト投げると適当な応答が帰ってくるだけのシンプルなもの。

必要なパラメータが欠落してたり、異常なパラメータ(例えばintであるべきものに英字が入ってたりとか)のときに、ちゃんと異常時として想定した振る舞いをする

ことを主にテストするという感じですね。

要素技術としてはFrisbyがよさ気かなと思って現在絶賛調査中です。Javascript力が低い自分としても自然にかけてけっこういい感じで、目的は達成できそう。

いろいろ前提すっ飛ばすけど、「異常時に相手側のアプリが突然死したらテスト側はどういう振る舞いになるんだろう」と疑問に思ったので調べてみました。

とりあえず、「あるリクエストを投げると死ぬ」Webアプリを作って、それを叩いてみれば分かるんじゃないかな？と。

そういうアプリをさくっと作りたければSinatraかなーと。こんな感じ。

んでこんなテストを書く。

実行してみると：

$ jasmine-node suicide_spec.js
hello!
.F
Failures:
  1) Frisby Test: suicide test 
        [ GET http://localhost:4567/suicide ]
   Message:
     Expected 500 to equal 200.
   Stacktrace:
     Error: Expected 500 to equal 200.
    at null.<anonymous> (.../node_modules/frisby/lib/frisby.js:493:42)
    at null.<anonymous> (.,./node_modules/frisby/lib/frisby.js:1074:43)
    at Timer.listOnTimeout (timers.js:92:15)
Finished in 0.163 seconds
2 tests, 2 assertions, 1 failure, 0 skipped

お、ちゃんと500として検知できた。

まあ本当は間に色々挟まってたりしてカンタンではないのかなとは思うのですが、それはおいおい詰めていけばよいかなと。

*1:何なら詳しいんだよ、といわれると、また、困るんだけど……。

LibreOfficeのリリースノートを訳すときに考えること

LibreOffice Translation

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

ついったに書いたのをまとめておきます。

これはあくまでも私はこうしている、というだけの話で、LibreOffice日本語翻訳コミュニティの総意でもなければ、査読をするならばこういう風にしなさい、という意味でもないです。

ちょっと補足必要かな。 もちろん、査読者として「この翻訳は妥当かどうか」をチェックする責任はあります。

ただ、UIの翻訳というのは、やってみれば分かるんですが、「英語を見て日本語を見て、対応があっていればOK」とはいえないところに難しさがあるのですよね。 極端な例を上げれば、「Line」という単語だけで「行」なのか「線」なのかを知ることはできなくて、それがどこで使われてるかをチェックする必要がある。 「Property」という単語が「プロパティ」なのか「属性」なのかは、同じ文脈の既存の翻訳がどうなのかを調べて併せる必要がある。

で、そういうチェックをやってから提案を上げてくださる方と、そうでない方というのはやっぱりいるのです。それは査読してれば分かるのです。ので、査読者の私としては「あ、この人なら大丈夫だな」と思う人については、字面のチェックだけで通しちゃうことがままあるということ。褒められた話ではないけど、未翻訳のまま放置されるよりはいいでしょうと。

お断りしておきたいのは、そういうチェックをしなきゃダメということではなく、例えば統計とか財務とかの専門性が高い用語については、そういうことは後回しで分かる人がとにかく訳してくだされば、あとからチェックはできるんでいいんですよ。だから査読ってシステムがあるわけで。そゆ意味で、萎縮はしないでくださいね。

さて次。

これはあんまり説明の必要はないですね。昔はけっこう悩んで、自信がない奴は入れないって態度だったんだけど、それはタイムベースリリースの利点を生かしてなくて、査読者としてはよくない態度だ、的な注意をうけて、それから新規翻訳については大胆になることにしました。

これはやはり、「一度定着した語を変えるというのは、昔のユーザーに変化を強いることになるので、それなりに慎重に決めたい」と思うからです。そしてLibreOffice日本語翻訳の議論の場はMLなので、MLで「こういう風にしたほうがよい」というコンセンサスがなければ、私はその査読を（個人としては新しい提案のほうが確かにいいな、理にかなってるな、と思っても）取り込むことはないですね。

ただ、ここで「うーん、いい感じだけど、説明がないから、今は入れない」と決めた奴を、提案そのままにして残しておくと、「新規の提案を虱潰しに査読する」フェーズのときに邪魔になるんですよねえ。でも議論することなく破棄しちゃうともったいないなーと思って捨てられない。悩ましい。

年単位で保留されてる奴は、MLで棚卸して提案者からコメントがない限り破棄、みたいなことやったほうがいいのかなあ。

最後は、これはついで。まあ当たり前といえば当たり前。

……こんな記事を書いてないで、翻訳を進めればいいのにね＞じぶん

ま、そんな感じでやってますということで。参考にでもなれば幸い。

LibreOfficeをコマンドラインで使うと便利だよ

AdventCalendar2015 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ディストリビューションでも同じなのだと思います。