2012年6月10日日曜日

lcrt日本語化作業の覚書

lcrt (http://code.google.com/p/lcrt/, https://github.com/niutao/lcrt) というリモートログインツールがあります。自機からSSHでリモートコンピューターと接続することが多い人には便利なツールだと思います。

このアプリケーションの利点としては、

  • 接続セッションが保存可能なのでいちいち入力せずともOK
  • 1つのウィンドウのまま複数の接続セッションを同時に実行できる(タブ使用可能)
  • 接続セッションの複製が容易
  • ローカルシリアルポートの接続をサポート
  • 比較的軽量
といった点が挙げられましょうか。(このアプリケーションに注目したのは、筆者がSSH接続の手間を若干煩わしく思っていたことに起因します)

多少なりとも使用してみた感触としては、長らくの開発停止状態から近年漸く再始動したWindows用ターミナルエミュレーターPoderosa (http://ja.poderosa.org/) に近い印象を抱きました。現状ではPoderosaほど機能は充実していませんが、開発は継続しているようなので、今後の発展に期待できるアプリケーションと言えましょう。

日本語化着手

さてこのlcrt、現在のところ日本語化はされていません。使われている英語はさほど難しいものではなく、SSHを普段から活用している人なら感覚で使いこなせそうなものですから、使用上大きな障害とはならないはず。しかし、そう言って放置するといつまで経っても誰も翻訳しないので、着手することにしました。

何この方式?

FLOSSに関わっている方々の中では、多言語対応にするため広く用いられているツールにgettextがあるのは周知の事実でしょう。lcrtもGTK+を使っているアプリケーションなので、gettextを利用しているのだろうと思っていたのですが……。

結論から述べるとlcrtのソースにはgettextで用いられる.poファイルが存在しません。かといって、Qtアプリケーションで用いられるような.tsファイルもありません。ならば、どのような形式のファイルが用意されていたかというと、C言語用のファイル(hoge.cとfuga.h)でした。しかも、最終的にはsqliteデータベースに格納されるという、今までにみたことがない方式。lcrtには表示言語を容易く切り替えられる設定があるので(勿論言語対応がされている範疇で)、その辺りと関わりがあるのかも知れないですが、稀な方式であることに違いはありません。

取り敢えずやってみよう

見慣れない方式とは言え、「原理からすれば日本語用の.cと.hがあれば取り敢えず何とかできるだろう」という安易な発想から英語用のen_US.cとen_US.hをコピー&リネーム(ja_JP.cとja_JP.h。ja_JP.cが日本語用ファイルの本体)して、作業を開始しました。

static struct lcrt_language_config ifile = {
    .table_name = LCRT_IFILE_TABLE,
    .members = LCRT_F_NUMBER,
    .config = {
         {"f_menuitem",                      "ファイル(_F)"},
         {"f_connect",                       "接続(_C) ..."},
         {"f_quick_connect",                 "クイック接続(_Q) ..."},
         {"f_connect_in_tab",                "タブで接続(_B)"},
         {"f_reconnect",                     "再接続(_R)"},
         {"f_reconnect_all",                 "全て再接続(_A)"},
         {"f_disconnect",                    "切断(_D)"},
         {"f_disconnect_all",                "全て切断(_O)"},
         {"f_clone_session",                 "セッションを複製(_N)"},
         {"f_lock_session",                  "セッションをロック(_K) ..."},
         {"f_print",                         "印刷(_P)"},
         {"f_print_setup",                   "印刷設定(_U) ..."},
         {"f_log_session",                   "セッションを記録(_L)"},
         {"f_recent_session",                "最近のセッション"},
         {"f_exit",                          "終了(_X)"},
    }
};/

ja_JP.cの内容は概ね上記のような感じになっています。一見してgettext方式とは異なることが判りますが、原文を日本語化しつつアクセラレーターが入っているものはしっかりと入れていくという作業自体の流れは、gettext方式と何ら変わるところがありません。

問題はmake関連ファイルの修正

日本語翻訳がある程度進行した状態で、一度バイナリをビルドして状態を確認しておく必要があるかなと思い、ビルドを試みました。gettext方式の場合、追加言語用のソース修正作業はしなくても問題なくビルドできることが往々にしてありますが、今回は必要でした。しかし、今までに経験したことがない方式なので勝手が違います。調べた結果、

  • lcrt/language/Makefile.in
  • lcrt/language/language.c
  • lcrt/language/language.h
の3ファイルでja_JP.cとja_JP.hに関する修正を施す必要があることが判りました。

最初は以上の修正でOK…と考えていましたが、この修正だけでは日本語ファイルのsqliteデータベースを作成しません。何が原因かと更に調べた結果、

  • lcrt/language/Makefile.am
の修正も必要と判明。どうやら、上記ファイル中の
#include "mkconfig.h"
#define LCRT_SUPPORT_LANGUAGE 3
#define LCRT_LANGUAGE_NUMBER 18
の"LCRT_SUPPORT_LANGUAGE"を修正する必要もあったようです。("LCRT_SUPPORT_LANGUAGE"は予め用意されていた言語数(英語・ドイツ語・簡体字中国語)。4に修正することで日本語も含まれるように)

以上の修正に加え、ja_JP.cとja_JP.hの中でen_US.cとen_US.hに由来する部分もsqlite日本語データベースに対応するよう修正した後でビルドを試みたところ、漸く日本語化ができました。

終わりに

ソースを参照した最初の感想が、「何故gettext使ってないの?」でした。gettextを利用せず、敢えてsqliteを使用した製作者の意図を推し量ることはできませんが、何らかのメリットがあるとは推測されます。ただ、lcrtの方式は翻訳者にとってはgettextを利用する方式と比較すると

  • 原文確認がしにくい
  • 作業が煩雑になっているのでは?
という印象を作業を通じて抱きました。果たして今後このような形式を採用したアプリケーションは登場するのでしょうかね……

0 件のコメント:

コメントを投稿