2014/12/30

  09:01:00 by , Categories: Freesoftware and Open Source Software

通常、アプリケーションの翻訳では、gettextなどのライブラリに
よって、メッセージやメニュー等がDB化され、PO ファイル等の形式になっています。
poeditなどの編集ツールや、汎用のエディタでも編集できますが、
Transifex(https://www.transifex.com/)やTranslateWiki(https://translatewiki.net/)を使うと
便利だとされています。

便利なのは、翻訳メモリという機能が利用できるためです。

詳しくは、OSCでもおなじみのエラリーさん(@brandelune)のOSPN記事が分かりやすいです。
http://www.ospn.jp/press/20101109no3-useit-oss.html

ほかにもこのへんが分かりやすいです。
http://www.slideshare.net/katayama2004/ss-20582795

さて、翻訳メモリで著名なツールは、OSSだとOmegaTです。
OmegaTでは、辞書引きの機能がついています。
StarDictという形式の辞書が使えます。英辞郎のような辞書を変換すれば便利そうですね。
このあたりのことは、以前に書きました。

さて、今月は、OSMの団体のOSMFJの定款を翻訳するというとりくみをしています。
この翻訳を正確に効率良く行うために、ちょっとした工夫をしました。

OmegaTは、チーム連携機能があるので、Githubなどで共有しながら翻訳を協力して
行なっています。
https://github.com/osmfj/teikan-translate

続いて、翻訳の参考例を増やすために、
法務省の日本法令外国語訳データベースシステムから、法令の日本語、英語の対訳を入手し、
http://www.japaneselawtranslation.go.jp/?re=01
法令関係の和英辞書を生成すると共に、用例から翻訳用例DB(tmx)を生成しました。

https://github.com/miurahr/jlaw-tmx

辞書は、 OmegaTのdictionaryディレクトリへ、用例tmxはtmディレクトリに配置することで
翻訳を効率良くしています。その他、フリーの辞書もプロジェクトに配置して、チームメンバーが同じような環境で
翻訳に協力できるようにしています。

2014/12/29

  14:35:00 by , Categories: Freesoftware and Open Source Software, Linux

OmegaTでは、StarDict辞書を使えることを前回触れました。
前回は、英字郎の辞書ソース(TXT形式)をstardict形式に変換できました。

StarDictで使うためには、 /usr/share/stardict/dic/ へ、前回作製したファイルを配置することで使い始めることができます。

さて、OmegaTでは、プロジェクトディレクトリのdictionaryへ配置すれば良いことを前回に述べました。しかしながら、おそらくそのままでは、一向に利用できないものと思います。

というのは、


14101: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/reiji-136.ifo': 10490ms
14101: FINER: File '/home/miurahr/translate/dictionary/eiji-136.dict.dz' added
14101: FINER: File '/home/miurahr/translate/dictionary/reiji-136.idx' added
14101: FINER: File '/home/miurahr/translate/dictionary/reiji-136.dict.dz' added
14101: FINER: File '/home/miurahr/translate/dictionary/waei-136.idx' added
14101: FINER: File '/home/miurahr/translate/dictionary/waei-136.ifo' added
14101: エラー: Uncatched exception in thread [DirectoryMonitor]
14101: エラー: java.lang.OutOfMemoryError: Java heap space
14101: エラー: at java.util.Arrays.copyOf(Arrays.java:2271)
14101: エラー: at java.io.ByteArrayOutputStream.grow
(ByteArrayOutputStream.java:113)
14101: エラー: at java.io.ByteArrayOutputStream.ensureCapacity
(ByteArrayOutputStream.java:93)
14101: エラー: at java.io.ByteArrayOutputStream.write
(ByteArrayOutputStream.java:140)
14101: エラー: at org.omegat.util.LFileCopy.copy(LFileCopy.java:90)
14101: エラー: at org.omegat.core.dictionaries.StarDict.readFile
(StarDict.java:193)
14101: エラー: at org.omegat.core.dictionaries.StarDict.readHeader
(StarDict.java:95)
14101: エラー: at org.omegat.core.dictionaries.DictionariesManager.fileChanged
(DictionariesManager.java:96)
14101: エラー: at org.omegat.util.DirectoryMonitor.checkChanges
(DirectoryMonitor.java:156)
14101: エラー: at org.omegat.util.DirectoryMonitor.run
(DirectoryMonitor.java:96)

こんなふうにメモリ不足エラーになってしまうからなのです。

OmegaTは、いまのところ辞書をすべてメモリー上に読みこもうとします。
英字郎のように大きな辞書を読もうとすると、既定のメモリ上限にすぐに達してしまいます。

そこで、/usr/bin/omegat/usr/local/bin/omegat(インストール方法によりパスは異なる)をエディタで開いて(スーパーユーザで編集してください)、メモリ上限を上げる必要があります。

既定では


#!/bin/bash
# readlink follows any symbolic links to get the real file
REALOMEGATPATH=`dirname "$(readlink -nf $0)"`
java -jar -Xmx512M "${REALOMEGATPATH}/OmegaT.jar" $*

こんなになっていますので


#!/bin/bash
# readlink follows any symbolic links to get the real file
REALOMEGATPATH=`dirname "$(readlink -nf $0)"`
java -jar -Xmx2048M "${REALOMEGATPATH}/OmegaT.jar" $*

のように上限設定を2GBへ変更してやります。 32ビットのWindowsなど、古いPCでは、利用可能なメモリが少な過ぎで利用できませんから、64bitのLinuxなど最新のOSと、メモリ搭載量の多い比較的新しめのPCを使ってみてください。

さて、これで辞書の利用はできるようになりますが、辞書引きが利用できるようになるために、最初にすごく時間がかかります。


37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/reiji-136.ifo': 6587ms
37202: FINER: File '/home/miurahr/translate/dictionary/eiji-136.dict.dz' added
37202: FINER: File '/home/miurahr/translate/dictionary/reiji-136.idx' added
37202: FINER: File '/home/miurahr/translate/dictionary/reiji-136.dict.dz' added
37202: FINER: File '/home/miurahr/translate/dictionary/waei-136.idx' added
37202: FINER: File '/home/miurahr/translate/dictionary/waei-136.ifo' added
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/waei-136.ifo': 17402ms
37202: FINER: File '/home/miurahr/translate/dictionary/ryaku-136.idx' added
37202: FINER: File '/home/miurahr/translate/dictionary/eiji-136.ifo' added
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/eiji-136.ifo': 45780ms
37202: FINER: File '/home/miurahr/translate/dictionary/ryaku-136.ifo' added
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/ryaku-136.ifo': 5818ms
37202: FINER: File '/home/miurahr/translate/dictionary/ryaku-136.dict.dz' added

わたしの2010年ころの4コアの Core i7, SSD diskの利用でも80秒ほどかかっています。2GB分近くメモリ上にデータを読み込んで展開しているわけで、当然と思います。

このあたりは、辞書そのものをメモリーに読み込まず、一時ファイルに圧縮展開後、mmap するような作りにすべきだと思います。OmegaTはJavaで書かれているので、すこし難しいのかもしれないですね。

2014/12/27

  22:48:00 by , Categories: Freesoftware and Open Source Software, Linux

翻訳作業を多数行う方は、翻訳メモリを使っていることと思います。
商用では、Tradosが有名のようですが、もっぱら私はOmegaTを使っています。

OmegaTでは、辞書引きの機能があり、StarDict形式の辞書をプロジェクトのdistionaryディレクトリに配置することで、自動的に辞書を引いて画面に表示してくれるようになっています。

そこで、これまでEPWING形式の辞書をEBViewで閲覧していたのですが、StarDict形式の辞書を作って、利用することにしました。

既に、StarDict形式への変換について、複数の方がブログに書いています。
sora_hさんは、 http://codnote.blogspot.jp/2010/01/i-installed-stardict-and-eijiro.html PDIC for WinをLinuxでWINEを使って動作させ、変換することで作業していました。

Design Recipe 別館Blog http://blog.designrecipe.jp/2011/01/01/eijiro-stardict-memo/ では、短いRubyプログラムを使って、実現されていました。

TXT形式のオリジナルのデータを持っていますので、後者の方法を試すことにしました。

スクリプトpdic1line2tab.rbは次のとおりです

<pre>
#!/usr/bin/env ruby
# -*- coding: utf-8 -*-
ARGF.each do |line|
line.gsub!("■・", "\\n・")
line.gsub!(/■/, '')
attr = nil
line.sub!(/ \{(.+?)\}/) do |e|
attr = $1
''
end
key, content = line.split(' : ')
next if content == nil
content = "【#{attr}】" << content if attr
puts [key, content].join("\t")
end
</pre>

使い方ですが、辞書ソースをUTF8に変換し,改行コードも整形したうえで、このスクリプトを通します。

$ iconv -f SJIS-WIN -t UTF8 EIJI-136.TXT | sed -e 's/^M//g' | ruby pdic1line2tab.rb > eiji-136.tab

StarDict形式に変換するために、 stardict-toolsパッケージを導入します。
apt-get install stardict-tools

そして
$ /usr/lib/stardict-tools/tabfile eiji-136.tab

実行したeiji-136.tabファイルのあるディレクトリに、stardict形式の辞書ファイルが3つ出来ます。

さて、Ubuntu /Debianに含まれているStarDict-toolsは、3.0.2バージョンです。このバージョンには、レコードの重複を許さないという仕様が有ります。3.0.1までと、3.0.3以降は、重複OKであるため、これは仕様バグです。

https://code.google.com/p/stardict-3/issues/detail?id=37

実際にバグ報告37番として報告され、修正されています。

Ubuntu/Debianのパッケージでは、この修正は含まれていませんので、パッチが必要です。
パッケージをソースからコンパイルすることで対応します。

パッチは、stardict-tools-tabfile-fix-issue37.diffを取得します。

以下は、パッケージの再ビルド例です。

$ apt-get source stardict-tools

$ apt-get build-dep stardict-tools

$ cd stardict-tools-3.0.2

$ quilt import ../stardict-tools-tabfile-duplication-fix-issue37.diff

$ quilt push -a

$ debuild -us -uc -b -i

できあがったパッケージをインストールしましょう。

$ sudo dpkg -i stardict-tools-3.0.2_2build2_amd64.deb

2014/10/14

  09:51:00 by , Categories: OpenStreetMap

Link: http://stateofthemap.jp/2014/

State of the Map JAPAN 2014が、12月13日(土曜)に東京大学の駒場キャンパスで開催される。
多くの来場者と講演が予想されるため、開始時間が11時に早められることになった。

講演枠のCFP(Call for presentation)が現在行なわれており、今週末18日に締め切られる。

はじめての日本だけのSotM開催とあり、技術解説、ビジネス活用、自治体での活用や期待、防災などの発表が行なわれる見込みだ。

11月にはライトニングトーク枠の募集が行なわれ、全国のコミュニティ活動について、報告される。

http://stateofthemap.jp/2014/cfp/

サイトで会員登録すると、プロフィールを登録するダッシュボードが表示される。
そこで、プロフィールを登録すると、CFP提出メニューが現れる。
すべてWebブラウザで完結するので、ぜひ気軽に提案してほしい。
講演は、Q&A含めて、15分または20分枠となっている。

2014/09/06

  14:43:00 by , Categories: Freesoftware and Open Source Software, Linux, Programming, Devops

Link: http://minimul.com/ssh-and-scp-into-a-vagrant-box.html

Vagrantは便利ですね。
vagrantで作業中にscpしたくなることがあります。virtualboxやkvmなど、ローカルのVMの時は、そんなに面倒ではありません。
しかし、AWSプロバイダーのようにクラウドを使っている場合、アドレス等が決め打ちできないので、面倒デス。

そんな時は、vagrantでssh設定を生成すればいいのです。


vagrant ssh-config > ./vagrant.ssh.config
scp -F vagrant.ssh.config default:/etc/httpd/conf.d/ssl.conf ./

このようにすると、いちいちインスタンスのIPアドレスを調べなくても、SCPできます。やったー。

  14:12:00 by , Categories: Freesoftware and Open Source Software, Linux

Link: http://theandystratton.com/2012/ssh-returns-too-many-authentication-failures-error-hostgator

リンク先の記事のおかげで、問題が解決した件を記します。

情報セキュリティに敏感になってきたので、漏洩リスクを下げるために、SSHキーを使いわけるようになりました。
Publicキーについても、GithubやAWSなど、登録するサービスが有るのですが、別々にするようにしています。

そしたらですね、エラーがでるようになりました

Too many authentication failures for username

なぜそうなるかというと、Gnomeの環境では、.sshの下にあるSSHキーを、ログインのときにすべてssh-agentに登録するわけです。
sshログインの時は、ssh-agentに登録されているキーを順次適用してログインできるか試します。
あまりたくさんのキーが.sshの下にあると、上記のエラーになるというわけです(たくさんと言っても、5ことか6こでエラーになります)

Amazon Web Service EC2を使うと、ログイン用のKey Pairを、Webから創ることができます。
sshコマンドで、 -i オプションをつけることで指定できる、とされています。

しかし、上記のような事象が起こる環境ですと、-i オプションにつけた鍵を試す「前に」,ssh-agentに登録された鍵を試してエラーになっちゃうので、ログインできないという事象が起こります。

そのため、ここ1週間くらい、ちょっと悩んでしまいました。(調べる余裕なかったし)

でも割合簡単に解決しました。

Full story »

2013/09/15

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

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

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

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

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

typical configuration of tileman

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

さて、上記の処理を行うために、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章計算幾何学の中に、17.11多角形分割 として解説されており、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が生成された複数の凸多角形のデータです。

::