Code readers daily

Link: http://qiita.com/advent-calendar/2015/osmjp

この記事は OpenStreetMap Advent Calendar 2015 の１０日目の記事です．昨日の記事は，　駅の位置を修正しよう　でした．

OpenStreetMapで、編集するようになると、頻繁にOpenStreetMap Wikiを参照するようになると思います。このWikiの日本語への翻訳については、ボランティアによって行なわれています。 今日は、この翻訳を効率的に行う方法について記します。

翻訳メモリ

いきなりですが、プロの翻訳家は、おおよそ全ての方が、「翻訳メモリ」なるものを使っています。これは何者でしょうか。Wikipediaを見てみましょう。

翻訳メモリは、翻訳を仕事とする人の業務の効率化と質の向上を支援するためのソフトウェアである。「翻訳メモリ」は厳密には原文と訳文のデータベースを指し、それを利用するソフトウェアは「翻訳メモリ ツール」と呼ばれる。「翻訳メモリ ツール」のことを「翻訳メモリ」と呼ぶことも多い。
従来型の翻訳メモリには、通常翻訳ソフトのような構文解析機能はない。したがって、翻訳メモリ ツールを使用することによって、原文が自動的に翻訳されることはない。翻訳自体はあくまでも翻訳者が行う。ただし、近年では翻訳メモリ ツールと翻訳ソフトを統合することにより、さらに効率の良い翻訳支援環境が実用化されている。
翻訳メモリの主な機能は

• 翻訳者によって書き起こされた翻訳を、その原文とともに、専用のデータベースに登録すること 
• 過去にデータベースに登録された翻訳を、同じまたは類似の原文が出てきたときに自動的に引用すること

 である。これらの機能によって、

• 同じ文章を繰り返し翻訳する 
• 文章を手作業で複製し貼り付ける

 などのこれまで翻訳者に任されていた単純作業を自動化し、さらに 同じ文章や類似した文章の翻訳における表現の統一 も自動化されるため、文書全体としての翻訳品質の向上も期待できる。(Wikipedia: 翻訳メモリの項目）

なんだか、いきなり難しくなってしまいました。素人が翻訳を聞くと、インターネットの翻訳サイトみたいに、機械翻訳をしてくれるように思いますが、そうではなくて翻訳は翻訳家が行うのですが、辞書引きや用語統一、過去の翻訳事例から適切な文をもってくるなど、翻訳に必要な作業を別々のアプリやネットを使わなくてもできるように支援するソフトということになります。このようなカテゴリのソフトをCATツール（Computer Aided Translationの頭文字）とも、呼びます。

このジャンルのソフトウエアやサービスには、次のようなものが知られています。Google翻訳者ツールキット、OmegaT、SDL TRADOSなど。

OmegaT（オメガティ）

OmegaTは、Javaで書かれた様々なプラットホームで稼働できるフリーソフトウエアです。プロジェクトのホームページから無償でダウンロードできます。マニュアルも整備されています。

画面左側には、原文表示と翻訳文の入力を行う編集画面が有ります。画面右側上には、これまでの編集結果から、参考となる訳文が示されます。右下には、用語集の検索結果や、辞書の結果が表示されています。

OpenStreetMap翻訳プロジェクトの取り込み

OmegaTには、チーム翻訳機能があります。皆さんの翻訳のとりくみ成果を共有できるように、日本語翻訳プロジェクトを公開しました。

OmegaTのメニューで、「プロジェクト（P)」ー「チームプロジェクトをダウンロード」を選択しリポジトリURLに　https://github.com/osmfj/osm-wiki-trans-ja.git を入力してください。

　一緒に活動いただける方はGithubのアカウントをつくり、プロジェクトページhttps://github.com/osmfj/osm-wiki-trans-jaでIssueとして参加表明してもらえればとおもいます。書き込み権限をつけたいとおもいます。OmegaTを終了するときに、更新するようになります。

　もし、チーム参加はされない場合は、チームのダウンロードの代わりに、上記プロジェクトからZipファイルでダウンロードをして、そのフォルダをベースとして開始されるといいでしょう。（https://github.com/osmfj/osm-wiki-trans-ja/archive/master.zip)r

OpenStreetMap Wikiの取り込み

メニューの「プロジェクト（P)」ー「MediaWikiから原文ファイルを追加」を選択します。OSM Wiki(wiki.openstreetmap.org)の翻訳したい英語メージのURLをコピーして、ダイアログに貼り付けます。

自動的に、原文を取り込んで、翻訳対象に加えてくれます。原文は、プロジェクトのフォルダの"source"に"original-source.UTF8"のような名称のファイル名で格納されます。この機能のおかげで、OSM Wikiのページを容易に取り込んで作業できます。

また翻訳メモリを使うことで、英語ページが更新された場合でも容易にその差分を検出することができます。これは、翻訳結果を直接記述するのではなく、一文ごとの対訳をデータベースとして保持しているため、もし元原稿が更新された時は、OmegaTにより差分が検出され、元の翻訳が近い訳文例として表示されます。そこで、差分だけ更新すれば、容易に追随できます。

辞書引き機能

OmegaTのプロジェクトディレクトリには、Dictionary　というディレクトリがあります。このディレクトリに辞書ファイルを置くことで、自動的に辞書を引いてくれます。現在のバージョンでは、StarDict形式に対応しています。今後、日本で標準的に使われているEPWING形式に対応する見込みです（私が機能を開発し、OmegaTプロジェクトに提案中です。）

自由に配布できる辞書は多くないのですが、グループプロジェクトではJim BreenによるJMDictという辞書を同梱しています。各自で購入した辞書も追加できます（私は、ジーニアス、英辞郎、海野辞書をつかっています）

今後のとりくみ

チームプロジェクトにおいて、用語集の整備、これまで翻訳されたWikiから例文作成が課題です。とりくみが進むほどに、効率がアップしていくことが期待されます。

分散タイルサーバを実現するTileManプロジェクトで、つかうため lua-nginx-osm ライブラリというのを、コアライブラリとして開発しています。

この中で、次のような機能を実現しています。

1. 　ポリゴン指定した地域をデータとして持っている。
2. タイルサーバで、タイル要求されたX/Y/Zoomについて、　そのタイルが、（１）の地域に含まれているかどうかを判定する。
3. 含まれている場合、タイルを生成する。

地域データは、geofabrikのデータを意識しています。

DBとして、特定の地域のデータだけPostGISに持っておいて、タイル要求がきたときに、それがDBに入っていればレンダリング実施、そうでなければ、アップストリームのtile.openstreetmap.orgへ要求、みたいな処理を実現しています。

これは、他の製品でもありそうな機能ですよね。

さて、上記の処理を行うために、is_inside_regionという関数を定義しました。計算速度を上げるために、
簡易なアルゴリズムを採用しました。ポイントは以下です

res = (y1 - y2) * nx + (x2 - x1) * ny + x1 * y2 - x2 * y1

(x1, y1) (x2, y2) は、地域を指定するポリゴンの一辺のベクトル
(nx, ny)は、判定するタイル要求の位置

上記は外積をとっており、全ての辺について判定して、すべて負でなければ、
すべての辺の内側に、判定するタイル要求の位置があることが分かります。

しかし、この判定ロジックには、弱点があり、比較するポリゴンは、かならず
convex polygon (凸多角形）である必要があるのです。

そこで、たとえば japan.kmlのような凹凸多角形(concave polygon)を凸多面体に分割することにしました。
単純なケースでは、手作業でも可能ですが、複雑になると、手作業では不可能になります。

このような問題は、計算幾何学で研究されていて、素晴らしいライブラリがすでに提供されています。
例えば、アルゴリズム設計マニュアルの下巻には、第17章計算幾何学の中に、１７．１１多角形分割　として解説されており、CGALというライブラリがつかえることが記されている。また、上記の判定についても、17.7 点位置決定で詳細に書かれている。

そこで、CGALを用いて、ポリゴンを複数の多角形に変換し、LUAのプログラムを生成するようなユーティリティプログラムを書くことにしました。

$ git clone https://github.com/miurahr/lua-nginx-osm.git
$ cd lua-nginx-osm
$ apt-get install libcgal-dev cmake make
$ make

これでプログラムが生成されるはずです。実行は、

$ utils/poly2lua/poly2lua -t

ここで(-t)をつけると、テストモードで、内蔵の日本の定義データを元に、複数の多角形（緯度経度）を示すデータを生成します。
また、osm/data/*.kml が元データで、 osm/data/*.luaが生成された複数の凸多角形のデータです。

Link: http://andymatuschak.org/articles/2008/05/07/more-on-launchpad-bazaar-vs-lighthouse-github/

最近、gpxviewerというアプリケーションをいじっている。これは、GPXファイルの管理を行う上で、容易に地図上でどこをトレースした物かを表示してくれる。
Python + GTKでかかれており、小さく、最低限必要な機能を満たしている。
多数のGPXファイルがあると、JOSMで開いて確認していくのでは、少々手間がかかりすぎる。また、できればファイル管理ソフトウエア(nautilus) から簡単に起動できた方がいい。

これは、まだリリースして日が浅く、コードベースも小さいので、こういった用途に向けて改良するには、ちょうどよかった。
わたしの改良点は、Githubリポジトリにおいてある。すでに、作者にパッチを送っており、gpxviewer on launchpadから最新のコードを入手できる。
５月に入ってから、７つのコミットに関わる貢献をしている。

さて、作者のAndrew Geeさんからは、BazaarをつかってLaunchpadにブランチを開いてくれ。そしたら、マージもレビューも簡単だ、といわれている。たしかに、bazaarを使ってlaunchpad からコードを入手して開発しているが、bazaarはその使い勝手が気持ち悪くて、git-bzrをつかって、(たとえば、git-bzrの使いかた),gitにインポートして開発し、ブランチの歴史をきれいにしてから、git format-patchを用いてパッチを生成して送っている。送ったパッチをそのままインポートしてくれれば、リポジトリに取り込むときに面倒はないのだけれども、Andrewは（bzrにそんな機能はないのかもしれないが）、パッチをあてて適当なコメントをつけてupstreamにマージをするので、パッチを送った後は、upstreamの最新から再度ブランチを切って作業をする羽目になる。

そもそも、プロジェクトのオーナーがlaunchpad+bazaarを使っているのだから、選択するのはオーナーだ。それに不満はない。けど、開発する方は、使いたい奴を使いたいではないか。

閑話休題

その選択にあたっても、プロジェクトオーナーは、pros/consがあって悩ましいはず。launchpadのサイトとしての機能はすばらしいが、bazaarよりgitのほうが使いやすいじゃん。という悩みをこの記事では吐露してくれているのである。

Link: https://launchpad.net/igotu2gpx

OpenStreetMap Japanでは、MAPコンシュルジュのご協力で、OSM Japan寄付付きi-gotU　GPXトラッカーの販売を行っていただいたことがある。当初は、Windowsのみの対応だったが、OpenStreetMap JapanのMLでご紹介したように、igotu2gpxというLinuxのクライアントが開発されていた。

最近、みたところ、大変な進化を遂げている。

• GUIが追加された
• 設定ができるようになった
• Windows/Macにも対応するようになった。

わかりやすいところで、GUIを見ていただきたい

起動時画面

地図をズームアップ、メニュー表示

これらのメッセージが日本語なのは、さっき翻訳したから。いずれ、取り込んでもらいます。地図は、もちろんOSMの成果を使っています。

Link: http://www.walking-papers.org/

Walking Papers(ウォーキングペーパー）は、OpenStreetMapプロジェクトに、プリンタと、スキャナーと、ペンで参加できるようになるサービスです。
基本的な道路がすでに、マップされていれば、その後の活動は、紙の上に、こんなレストランがあったとか、記入することで情報を埋めていくことができます。

基本的なローカライズの仕組みが入っていたために、日本語に翻訳して、反映を依頼していました。そして、日本語に対応しました！

日本語で利用するには、上のメニューから、「日本語」をクリックしてみてください。

まだまだ、翻訳がおかしいと自分でも思いますが、英語だと気後れする方には多少親切になっているはずです。

翻訳に貢献いただける方は、gitというシステムを利用して、
http://github.com/miurahr/paperwalking
からforkして、わたしにpullリクエストしてくださるか、メールやコメントでお知らせください。

Link: https://translations.launchpad.net/josm/trunk/+pots/keys

JOSMの翻訳にあたって、ボランティアの皆さんがとても悩んでいる。悩んだときには、launchpadのインターフェースで、「レビューが必要」というフラグをたてている。

この翻訳で難しいのは、正確には英単語の知識ではない。たとえば、"permissive"という単語を訳さないといけないのであるが、辞書を引けば"許容”とか、”許諾”とか、でてくるだろう。しかし、ここでは、この単語がでてくる、文脈のなかで、意味を見つけないといけない。
画面では、ヒントとして

Located in build/trans_presets.java:312 build/trans_presets.java:313 build/trans_presets.java:314 build/trans_presets.java:315 build/trans_presets.java:316 build/trans_presets.java:317 build/trans_presets.java:318 build/trans_presets.java:319 build/trans_presets.java:320 build/trans_presets.java:321 build/trans_presets.java:322 build/trans_presets.java:516 build/trans_presets.java:517 build/trans_presets.java:518 build/trans_presets.java:537 build/trans_presets.java:538 build/trans_presets.java:539 build/trans_presets.java:558 build/trans_presets.java:559 build/trans_presets.java:560 build/trans_presets.java:579 build/trans_presets.java:580 build/trans_presets.java:581 build/trans_presets.java:600 build/trans_presets.java:601 build/trans_presets.java:602 build/trans_presets.java:621 build/trans_pres
ets.java:622 build/trans_presets.java:623 build/trans_style.java:181

というように、この単語が登場する場所が示されている。ところが、ここにも落とし穴が。この示されているファイルは、プログラムをコンパイルするときに自動生成されるものであって、本当にチェックすべきは、このファイルではないのである。
ソースコードにおけるcore/presets/presets.xmlが観るべきファイルで、それをみると、たとえば

<combo key="access" text="Access" values="yes,private,designated,destination,permissive,agricultural,unknown,no" default="" delete_if_empty="true" />

のように、なっている。つまり、その道路の通行ができるかどうかの属性として、"yes,private,designated,destination,permissive,agricultural,unknown,no"の一つとしてのPermissiveの意味を見つけないといけないのだ。

実のところ、こういった値は、プログラムが勝手に決めているのではなく、コミュニティの議論によって決めたものだ。それは、プロジェクトWikiに地物の属性一覧として記載されている。

そこで、一覧を見ると、

General access permission.

* permissive means there is no legally-enshrined right of access, but the landowner has allowed it at his/her discretion
* private means access is restricted to the landowner
* destination is used for ways in designated local traffic areas, where traffic should only enter if its destination is within the area

とある。つまり、そこにすむ住民はその道路を使っていいけれども、それ以外は進入禁止だよ。ということだ。これでは、”許容”と訳していては、意味がわからない。結果として、「関係車両のみ可」くらいの訳にすることになる。

このように、JOSMの翻訳作業は、”メッセージの翻訳”を超え、文脈と地物に関連する意味を確認しながら進めていく作業なので、大変なのである。それに対して、

Contributors to this translation: Akihiro Ome, Hiroshi Miura, Ikiya, JIN, Katz Kawai, Kazuhiko NAKAMURA, MAPconcierge, caesium, hatochan, nazotoko, techstrom, yu nakayama.

こんなにもたくさんの方が、協力してくれているのである。感謝である。

Pages: 1· 2