2006年11月26日

続・メッセージ翻訳の難しさ

先月書いたメッセージ翻訳の難しさの続編です。前回よりも取り扱いの範囲がちょっと広いです。

まずは以前の記事へのコメントに対する返信ぽいものから。

一般的なメッセージ・用語の表記・準拠・参照について

翻訳者が他のOSやソフトウェアでどのような翻訳がされているのかを把握することは大いに推奨されると思っています。
しかしながらGimpがさまざまなプラットホームOS上で使われていることを考えると、例えばWindowsで使われている言葉だからといってそれをそのまま用いてよいかどうかは慎重に検討する必要があるでしょう。
それじゃあどのプラットホーム上で統一したほうがいいのかと考えると、GNOMEで統一するのが望ましいと思います。

The GNOME Translation Project (以下、GTPと略)
日本GNOMEユーザー会 (以下、JGUGと略)

Gimpは厳密に言えばGTK+アプリケーションの一つですが、ポジションからいえばGNOMEファミリーの一員でしょう。(しかしGimpというアプリケーション単独であちこちに出現しているからややこしくなる・・・)
実際、GimpはGTPに沿ったメッセージ作りになっており、現在のGimpメッセージ翻訳は日本GNOMEユーザー会で行われています。

JGUGで実際にGimpのメッセージカタログがどのように翻訳されているかといえば、主にJGUG内にあるGNOME Translatorsメーリングリストにて有志が翻訳を予約し、実際に翻訳したものをどこかにアップロードし、それを権限のある人が本家のCVSに反映させるといった流れになっています。


専門用語・特殊効果用語

グラフィック分野の専門用語やフィルタなどの特殊効果の用語を翻訳する場合について考えてみます。
この場合、先のコメントで指摘されていたようにPhotoshopの用語を見習うことはとてもよいと思います。アルゴリズムの違いによって全く同一の結果にならないエフェクトであっても、同じような効果を狙っているエフェクトであるなら同じ名前をつけてもいいかもしれません。
こちらの用語の場合でも、Photoshopだけではなく他の同種のソフトウェアではどのような言葉になっているのか把握しておくほうが望ましいです。


文法や文化的な背景の違い

しげっちさんの挙げていた例でいえば、「File→New...」は現在「ファイル→新規」となっています。
私が気になっていたところでいうと、選択メニューのところの項目が分かりにくいと思っていました。
#: ../app/actions/tools-actions.c:75
msgid "_By Color"
msgstr "色で(_B)"

上の「色で」は「色による選択」などといったように翻訳者が気を利かせてやるべきところじゃないかな。
言語や文化的背景が違うのですから、原文では妥当であっても自然な日本語に直すなら足りない言葉を補ったり別の言葉に置き換えたりすることが必要な場面があったりするでしょう。

>時には原文のカタログが酷くて訳せない場合もあります。
http://www.imou.to/~AoiMoe/column/win/could-not-be.html

Gimp-1.2のメッセージを翻訳している時でも同じようなケースが少しありました。なんとかごまかしましたが・・・。2.4でも残っているかどうかは不明です。

さらに別のケースですが、ちょっと理解に苦しむ場面。
text_tool_line_spacing.png
#: ../app/tools/gimptextoptions.c:475
msgid ""
"Line\n"
"spacing:"
msgstr ""
"行\n"
"間隔:"

そのまま「行間隔」としたいのに、"Line spacing"が長いからという理由で二行に分けられているケースです。逆に原文が短くて翻訳したものが長いためにダイアログの形が崩れてしまうというのが往々にして発生しています。(ダイアログが大きくなってしまうのは日本語の文字を小さくすると読みにくくなってしまうという事情もあるのでしょうけど・・・・・)
ja.po以外ではここがどうなっているのか調べてみると、他の言語でも二行に分けられているようでした。もしも「行間隔」が漢字一文字で表されるような分離不可能なものであったらどうなっていたのだろうな・・・と思ってしまいます。




Gimp-1.2のメッセージ翻訳をしていたとき、その翻訳物を本家CVSに反映させるにはどうすればいいのかをGimp開発者の人にメールで質問したことがあります。

その時の返信内容としては、
1) GTPのサイトをよく読むこと
2) gnome-i18nメーリングリストに入会しよう
3) 日本語を担当しているチームに連絡しよう(JGUGのことですね)
といったものでした。
もし自分の翻訳したGimpメッセージを本家に反映したいのであればJGUGの翻訳メーリングリストに参加してコミット要請するのが一番の近道でしょうね。


Gimpのメッセージだけではなく、ドキュメントやマニュアルを翻訳する前に目を通しておくとよいものを紹介します。もちろんJGUGやGTPのサイトや関連ページも読んでおくと良いでしょう。

・L10N Guidelines for Developers
http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html

これは主にプログラム開発者が自分のプログラムをI10N化(I18N化)する際にどういった手順で、何を注意すればよいのかをまとめたドキュメントです。
プログラム開発者だけでなく、翻訳者も一通り読んでおくことをお勧めします。どんなルールに基づいて翻訳対象ができあがっているのかを知っておいたほうがいいからです。

・日本語マニュアルの制作
http://developer.gnome.org/projects/gtp/style-guides/pdf/styleguide-ja.pdf

Sun Microsystems社がSolarisのマニュアルのローカライズを行った際のスタイルガイドです。SunのSolarisのためのスタイルガイドですが、GNOMEでも適用できるのでGNOME Localization Style Guidesに紹介されています。
マニュアルなどの翻訳を行う時に注意すべき点が具体例や翻訳例とともに書かれています。日本語に翻訳するときに発生する問題点についても述べられていて、とても参考になります。
これを読んで、今まで翻訳してきたGimpマニュアルの中で修正しないといけないような心当たりのある箇所がいくつも思い浮かびました。




トゥーディさんがコメントに書いた
メッセージの日本語翻訳は、メッセージを日本語へ変換することではなく、直感的に動作をイメージできる日本語のメッセージを探し出す、或いは創り出すことではないでしょうか
というのは、かなり高いスキルと経験を翻訳者に求めるものです。下手すれば本来の意味を損なってしまうかもしれません。
完成物の総合的な品質を高めるためのこととして、この指摘は核心を突いていると思います。翻訳者側の都合よりも利用者側の便宜を考えた翻訳を心がけたいものです。


posted by いっちー at 12:08| Comment(1) | Dialy | 更新情報をチェックする
この記事へのコメント
トゥーディと申します
興味深くこの記事を読ませていただきました。
また、記事中の文献の紹介は大変参考になりました。


さて、いろいろ考えるうちに次のようなことが浮かんできました。

「(プラットフォーム毎の)方言があってもええんちゃうか?」、と。 
(※ 共通語だと「(プラットフォーム毎の)方言があってもいいんじゃないかな?」)

あくまで一般的なメッセージ・用語の表記に限ってのことですが、ひとつの用語に統一せずプラットフォームごとに(”デスクトップ環境ごとに”と言ったほうが相応しいかもしれませんね)それぞれの環境での自然な用語を用いるのが、良いように思えてきました。

「"File > Save" は、『保存』だよ」(GNOME = 共通語)
「"File > Save" ちゅうたら、『上書き保存』やがなぁ」(Windows弁)

このことは、それぞれのプラットフォームでロケールデータを用意しなければならないということに他ならず、いくつかの問題が生じるであろうことは私も認識しています。(例えば、どの用語にプラットフォーム準拠を許すかという線引き、誰がそれぞれのロケールを整備管理するのか、ユーザー間のコミュニケーションに混乱が生じないか等々)

 一応、問題提起ということで・・・ 多数のご批判があるのは覚悟のうえで、ご意見をお聞かせ願いたいところです。

Posted by トゥーディ at 2006年11月29日 01:03
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。