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

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

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

書いたりしたもの（宣伝）

今日は時間がないのですが、取り急ぎ宣伝ですよ。

特集3「Ubuntuで動かすインクジェットプリンター」を書かせていただきました。

細かいフォローをしたいところもあるのですが時間がないのでそれは後日。狭いワンルームマンションにインクジェット複合機4台配置して原稿書きするのはちょっと大変でしたが、ライターあとがきにも書いたとおり、久しぶりに色んなプリンターをいじれて楽しかったです。

書きましたついでにもう一個、ここで紹介してなかったもの。

こんな本も書いてました。実は。

この本についてもまたいろいろフォローしたいことがあるんだけどまた別途。ちゃんと調べてないけど、MongoDBのRubyドライバーの今のインターフェースについて日本語で解説した書籍ってこれ以外にあるのかなあ。

別に買ってくださいというつもりはないですがご購入いただけるのであればアフィリンク使ってもらうと大変に喜びます。

LibreOffice Conference 2016 Brnoの落ち穂拾い

AdventCalendar2016 Event LibreOffice OpenSource

さてさて今年もやってきましたLibreOffice Advent Calendar 2016。この記事はその初日の記事です。

今年は表も裏もレポート書けないんですよねー。なにせ入院してたので。

本当は私が書くはずだったITProさん掲載の表のレポートは、榎さんが立派に書いてくれました（前編 / 後編）。この場を借りてお礼を申し上げます。無茶振りにもかかわらず書いていただいてありがとうございます。

で、今日は何を書こうかな。

お金とかそういう話

ヨーロッパにぶち抜き１週間で滞在するとなると、お金の面が気になる方もいるかなあと思いまして最初にこの話を持ってきました。……って前振りは去年の記事の流用です。

去年も書きましたが、今年もまたLibreOffice Conferenceは無料でした。私は入院しててほぼすべてのイベントをブッチしたのですが（会期前のコミュニティデー夜に開催されたウェルカムパーティだけ出た）、それ以外のパーティの類もすべて無料、お茶もお菓子もランチも無料だったと聞いています。スポンサーさまさまやで。

そんなわけでお値段は行き帰りの交通費と、現地の宿泊費だけになります。

費目 費用(日本円) 備考
航空券 96,910 ターキッシュエアライン 成田-イスタンブール-ウィーン
鉄道 5,000(*) ウィーン-ブルノ
宿泊 19,095 9/5〜9/10 6泊7日
計 121,005

(*) だったと思うんだけど、忘れてしまいました(^^;

去年に比べるとなんと安いことよ……。オーフスは航空券だけで270,940円だったもんなあ。

今はネットとかで航空券予約もラクショーなので、当然そうすると思うかもしれません。けど、私旅行とか全然しない奴ですしそもそも地理に疎いので、そもそもブルノってどこからどう行くのが便利なのかもわからん。これは窓口でプロに相談したほうがいいなーということで、普通にH.I.Sの銀座本店に行って「ぜんぜんわからんのですがチェコのブルノってところに行きたいです」といって候補を出してもらいました。

このチケットがそこそこ安かったのは日曜日の夜発ってところ（土曜発にすると+5万だったと思う）と、あとイスタンブール経由というのがもしかしたらあるのかも。今年6月末にイスタンブール空港で、ありましたもんね。ええ。それと、チェコのプラハ経由とウィーン経由、どちらも鉄道に乗ってる時間は同じぐらいで、でもウィーンのほうが便が多いせいか、少し安かったです。ここらへんは、いろいろ選択肢を持ってるプロの旅行会社に頼ってよかったなーと思うところ。

宿泊は安定のAirBnBです。日本国内だと私、ついお酒とか飲みすぎてよいお客様でいられる自信がなく、AirBnBの利用は躊躇われるのでございますが、海外だと気が張っているのかなんなのか、人とのふれあいがあるAirBnBたのしいなって思うのでした。ただ、今回のように入院騒ぎとか起こしたときには、ホストの善意に頼りきりになるので、リスクはリスクですね。今回のホストさんはすごい親切でよかったですけど。

コミュニティミーティングのお話

メインのカンファレンスについてはキーノートであるState of the Projectしか聞けなかったので（そのときも足が痛くて集中できなかった）、その前日のコミュニティミーティングについて。榎さんのレポートにも書いてありますが、全体のレポートの中の一部という意味ではあまり深入りできないわけですので。

といってもこの日もすでに具合はよくなかったのですべてを記憶できているとは言い難いですが、主な議題としては：

  • 自己紹介
    • 「私は日本から来たNaruhiko Ogasawaraで、主にUI翻訳のリードとかやってるよ」みたいなのを一言二言
    • 内輪受けですみませんが、TDFの秘書的な役割を持っているSophie Gautierという方がおりまして、QAとローカルチームも見てるし、カンファレンス担当でもあるので我々非常にお世話になっているんですが……「Sophie（の役割）はSophieとしかいいようがないね」「そうだね」ってところでみんな爆笑しておりました
  • グローバルのマーケティングについて
    • 特に台湾を始めとする極東マーケットについて
    • マーケティングの電話会議もたまにはアジアから参加しやすい時間にすべきであるみたいな
    • 日本からも参加してくれるよな？ と目を見てItaloに言われたので「もちろん」と言ったけどまだ参加したことないですゴメンナサイ
  • ローカライズ
    • 今のプロセスでなにか課題はないか？ みたいな話
    • 日本語翻訳コミュニティとしては今のプロセスでいいんじゃない？ masterの分離タイミングとかもいいと思うよ？みたいな意見を述べたり
  • コミュニケーション
  • 予算
    • 今年から、各国のNatvie Language Projectそれぞれに予算がつくようになったのですが
    • そもそも税金の処理的にNLPってお金受け取って大丈夫なんだっけみたいな話
    • 例えば旅費補助であれば旅行会社の口座にTDFから振り込む形みたいな方法も取れるよ、みたいな話があった気がする
    • ちょっと難しくてついていけなかったけど
  • MS Office互換？
    • インドから来た人だったかな？ が、「なんでLibOはMS OfficeとUIが一致してないんだ」みたいなことを急に吠えた
    • 「教科書的な答え方をすると……パッチはいつでも歓迎だよ」
    • 別にMS Office的なUIにすべきであるともすべきでないとも、決まった結論はないですよ
    • 議論をする場としては、やはりdesignチームなんだろうねーと

私なんかは英語あんまり得意じゃないし、そもそもオープンディスカッションに慣れてないということもあって、なかなか口を出していくのは難しいわけですが、せっかく会議の場にいるので、なんかしゃべりたいなーと思って頑張りました。オフラインの場合、オンラインに比べて身振り手振りも表情もあるので、通じやすいというメリットは生かした方がいいよなーと。

単に講演を聞くだけじゃなくて、こういうディスカッションの場があるのも、カンファレンスの楽しみだったりしますね。

おわりに

なんかうっすい話 and LibreOfficeにあまり関係ないことばかりで申し訳ないです！

まあ、カンファレンス本体に参加してないので、書けることは限られているのでしょうがないですね。でも、行って楽しかったですよ。1年ぶりにいろんな人と（時間は短かったけど）話せたのは、やっぱりよかった。

来年はローマです。観光地なので高くつくんだろうなあ。でも、楽しみです。See you in Rome!

チェコ入院の記録など

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:多少不安定でもいい！新しい機能をすぐ試したい！って人とか、不具合を踏んだらバグ報告して直してもらえる可能性がある！嬉しい！というマゾさん、という意味。ちなみに私は両方です。