1　はじめに
　Alephの日本語化の一環として，日本語検索の実現，利用者へ提供されるインターフェースの翻訳に加え，業務用画面の日本語化を行なった。本稿ではこの業務用画面（Graphic User Interface：以下，GUI）の翻訳について説明する。

2　GUI日本語化の作業

（1）基本構成部分の翻訳
　Alephの業務用画面には，業務内容に応じて以下の5つのモジュールが用意されている。
　・Acquisitions/Serials（発注・受入／雑誌）
　・Cataloging（目録）
　・Circulation（閲覧）
　・ILL（相互協力）
　・ALEPHADM（管理用インターフェース）

　GUIの翻訳にあたり，まずはこれらのモジュール画面内に表示されるボタンやメニュー項目等の翻訳を行なった。使用しないことが決まっていたILLを除く4モジュールを，日本語インターフェースの必要度を考慮したうえで，閲覧，発注・受入／雑誌，目録，最後にALEPHADMという順で対応した。各モジュールを独自の判断でひと通り翻訳した後に，プロジェクト室の各モジュール担当に確認を依頼し，以後，変更要望を随時反映させていった。
　翻訳作業は，翻訳を必要とするファイルのオリジナル版をコピーして日本語版ファイルを用意し，そのなかの原文（英語）を日本語に翻訳していく，という方法で行なった。GUIの基本構成部分の該当ファイルは，モジュール別にファイルが格納されており，ファイル名も明確なため，変更結果の確認がしやすく，変更要望への対応も比較的容易であった。

（2）レイアウト上の制約
　AlephのGUIは，Ex Libris社の方針により万国共通となっており，言語別に特化したインターフェースは存在しない。よって，例えばAlephに標準では用意されていない「氏名の読み仮名欄」が必要だとしたら，他のデータ項目を流用するしかない。（あるいは開発要求を出して，GUIに読み仮名欄を加えてもらう，という手もある。しかし多数のユーザーからの要望がない限り，実現は不可能に近いのが現状。）また，ボタンの大きさや，各項目見出しやデータの入力スペースのサイズなども，変更不可である。つまり，融通が利かないのだ。そのため，翻訳ファイル上では文字数制限がなくても，GUI上では表示幅の限界から文字が収まりきらない場合が多々あった。日本語表現を工夫するとともに，少しでも多くの文字を表示できるようにするため，止むを得ずショートカット表示（図1）は日本語GUIからは取り除くこととした。

（3）GUIメッセージの翻訳
　GUI上で行なう様々な操作に伴って表示されるメッセージは，全部で900ファイル（各ファイル内のメッセージ数はまちまちだが，多いものでは700行ほど）近く用意されていたため，こちらも業務遂行上必要と思われるものを優先して翻訳を行なった。極力実際の出現場面を再現しながら翻訳を行なったものの，どんな場面で使用されるメッセージなのか見当がつかないものも多かった。

　a　用語の選び方：複数モジュール間の場合
　GUIメッセージを日本語化するにあたって最も困ったのが，同一表現があらゆるファイル内に点在することである。例えば“item”という語は，閲覧モジュールにおいては「資料」，発注・受入／雑誌モジュールでは「アイテム」と訳している。Aleph全体で用語を統一してしまうことも考えたが，各モジュールのGUIを使って日々業務を行なうにあたり，より違和感のない表現を使うほうが望ましい，と判断したためである。よって，“Item does not exist”というメッセージがあった場合，この表現がどこに出現するかによって，訳し方を変える必要が生じる。ファイル名からおおよそのモジュールの見当がつく場合はいいものの，出現個所が特定できないメッセージもあり，それらについては一旦どちらかの形で訳し，実際に表示された時に違和感があれば対応する，という方法を取らざるを得なかった。

　b　用語の選び方：同一モジュール内の場合
　同一モジュール内においても，メッセージ内容とその出現個所によって，一つの語に対して複数の表現を使い分けるケースもあった。例えば“record”という語は，内容によって「レコード」「データ」「記録」「情報」，場合によっては「書誌」と訳した。その一方で，“record”“data”“document”の3つの単語は，日本語にするとどれも「データ」となってしまうことが多かったが，元の英文を比較しても，これら3つの単語の使われ方に明確な区別があるようには見受けられなかった。他にも“library”のように，頻出語であるにも関わらず，Ex Libris社が独自の使い方をしている（「データベース」の意で使用）語もあり，メッセージによっては，どちらの意味で使われているか，判断しかねるケースもあった。
　GUIメッセージは，ファイル数が膨大であることと，同一メッセージが複数存在することから，用語の変更要望があった場合，対象となるメッセージを見つけ出すのに時間を必要とした。場合によっては，複数の同一メッセージ中，実際に使用されているのがどれであるかを特定するために，可能性のあるメッセージに意図的にダミーの文字列を埋め込んで出現個所を確認したりもした。

（4）その他の翻訳対象ファイル
　キャンパス名や資料区分などのような，GUI上のプルダウンメニューに表示される選択項目は，各モジュールで使用される設定テーブルの値がそのまま反映される。Alephの導入に伴い，業務フローやコード体系の見直しが行なわれたこともあり，それらの設定テーブルの調整は，各モジュール担当がシステム担当に依頼する形で進められた。また, GUIから出力される帳票類の日本語版についても, 各モジュール担当とシステム担当とで調整が行なわれた。

3　作業所感：理想と現実
　GUIを日本語化するにあたり，システム全体として表現に一貫性を持たせ，的確に内容を伝えつつも極力日本語として不自然にならないように，ということを心掛けたつもりである。しかしながら，文字数などレイアウト上の制約は思ったよりも大きく，また先に挙げたように，同一メッセージが複数存在する一方で，日本語においては場面ごとに別の訳をあてたいにも関わらず，英語版では一つのメッセージが複数の箇所で兼用されてしまっているようなものもあり，頭を抱えてしまうこともしばしばあった。そして時には諦めも必要であった。この翻訳作業を通して，英語と日本語，それぞれの利点と不利点を，つくづく再認識させられたのだった。
　翻訳作業は，本来ならば，全ての業務に精通した者が行なうのが理想である。今回そのような状況ではなかったなか，業務やデータについてわかりやすく説明してくださったプロジェクト室の各モジュール担当およびシステム担当，そして現場の視点から数々のご意見をお寄せくださった各地区メディアセンタースタッフの皆さまに感謝したい。

4　おわりに
　日本語化の作業に終わりは無い。なぜならば，今後もAlephのバージョンアップが行なわれる度に，エラーメッセージの追加や，場合によってはGUIそのものの変更が生じるからである。今回慶應が行なった日本語化の作業は，あくまでも慶應にAlephを導入するために行なわれた作業であって，純粋な意味でのAleph GUIの日本語版としては，土台を作ったに過ぎないと個人的には思っている。今後日本においてAlephユーザーが増え，この土台を基に日本語版Alephがより良いものとなっていくことを，強く願うばかりである。