MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

Aleph で日本語を扱う―GUI の日本語化―
すぎの じ ゅ り あ

杉野珠梨亜（メディアセンター本部）

1 はじめに（あるいは開発要求を出して，GUI に読み仮名欄をAleph の日本語化の一環として，日本語検索の実加えてもらう，という手もある。しかし多数のユー

現，利用者へ提供されるインターフェースの翻訳にザーからの要望がない限り，実現は不可能に近いの加え，業務用画面の日本語化を行なった。本稿ではが現状。
）また，ボタンの大きさや，各項目見出しやこ の 業 務 用 画 面（Graphic User Interface：以 下，データの入力スペースのサイズなども，変更不可でGUI）の翻訳について説明する。

ある。つまり，融通が利かないのだ。そのため，翻訳ファイル上では文字数制限がなくても，GUI 上で2 GUI 日本語化の作業は表示幅の限界から文字が収まりきらない場合が（1）基本構成部分の翻訳多々あった。日本語表現を工夫するとともに，少しAleph の業務用画面には，業務内容に応じて以下の 5 つのモジュールが用意されている。
・Acquisitions!
Serials（発注・受入!
雑誌）でも多くの文字を表示できるようにするため，止むを得ずショートカット表示（図 1 参照）は日本語GUI からは取り除くこととした。

・Cataloging（目録）・Circulation（閲覧）・ILL（相互協力）
・ALEPHADM（管理用インターフェース）
GUI の翻訳にあたり，まずはこれらのモジュール画面内に表示されるボタンやメニュー項目等の翻訳を行なった。使用しないことが決まっていた ILLを除く 4 モジュールを，日本語インターフェースの図 1. 閲覧 GUI 上のボタン
英語版ボタンの先頭の「R」がショートカットを表わしており，「Alt+R（下線文字）」でその操作がマウスを使わずに行なえる．日本語の場
合は「選択資料を更新（R）」と表記することで実現可能．ただしこの例の場合，ボタン内には収まらない．

必要度を考慮したうえで，閲覧，発注・受入!
雑誌，目録，最後に ALEPHADM という順で対応した。各（3）GUI メッセージの翻訳モジュールを独自の判断でひと通り翻訳した後に，GUI 上で行なう様々な操作に伴って表示されるプロジェクト室の各モジュール担当に確認を依頼

メッセージは，全部で 900 ファイル（各ファイル内し，以後，変更要望を随時反映させていった。のメッセージ数はまちまちだが，多いものでは 700

翻訳作業は，翻訳を必要とするファイルのオリジ行ほど）近く用意されていたため，こちらも業務遂

ナル版をコピーして日本語版ファイルを用意し，そ行上必要と思われるものを優先して翻訳を行なっのなかの原文（英語）を日本語に翻訳していく，とた。極力実際の出現場面を再現しながら翻訳を行いう方法で行なった。GUI の基本構成部分の該当なったものの，どんな場面で使用されるメッセージファイルは，モジュール別にファイルが格納されてなのか見当がつかないものも多かった。

おり，ファイル名も明確なため，変更結果の確認がaしやすく，変更要望への対応も比較的容易であった。

GUI メッセージを日本語化するにあたって最も（2）レイアウト上の制約
Aleph の GUI は，Ex Libris 社の方針により万国用語の選び方：複数モジュール間の場合困ったのが，同一表現があらゆるファイル内に点在することである。例えば

itemという語は，閲覧共通となって お り，言 語 別 に 特 化 し た イ ン タ ー

モジュールにおいては「資料」，発注・受入!
雑誌モフェースは存在しない。よって，例えば Aleph に標

ジュールでは「アイテム」と訳している。Aleph 全体

準では用意されていない「氏名の読み仮名欄」が必で用語を統一 し て し ま う こ と も 考 え た が，各 モ要だとしたら，他のデータ項目を流用するしかない。

ジュールの GUI を使って日々業務を行なうにあた28

MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

り，より違和感のない表現を使うほうが望ましい，ム担当に依頼する形で進められた。また，GUI からと判断したためである。よって，Item does not ex-

出 力 さ れ る 帳 票 類 の 日 本 語 版 に つ い て も，各モ

ist というメッセージがあった場合，この表現がどジュール担当とシステム担当とで調整が行なわれた。

こに出現するかによって，訳し方を変える必要が生じる。ファイル名からおおよそのモジュールの見当

3 作業所感：理想と現実がつく場合はいいものの，出現個所が特定できない

GUI を日本語化するにあたり，システム全体としメッセージもあり，それらについては一旦どちらかて表現に一貫性を持たせ，的確に内容を伝えつつもの形で訳し，実際に表示された時に違和感があれば極力日本語として不自然にならないように，という対応する，という方法を取らざるを得なかった。

ことを心掛けたつもりである。しかしながら，文字b 用語の選び方：同一モジュール内の場合数などレイアウト上の制約は思ったよりも大きく，同一モジュール内においても，メッセージ内容とまた先に挙げたように，同一メッセージが複数存在その出現個所によって，一つの語に対して複数の表する一方で，日本語においては場面ごとに別の訳を現を使い分けるケースもあった。例えば record とあてたいにも関わらず，英語版では一つのメッセーいう語は，内容によって「レコード」「データ」「記録」ジが複数の箇所で兼用されてしまっているようなも「情報」，場合によっては「書誌」と訳した。その一のもあり，頭を抱えてしまうこともしばしばあった。

方で，record data

document の 3 つの単語は，そして時には諦めも必要であった。この翻訳作業を日本語にするとどれも「データ」となってしまうこ

通して，英語と日本語，それぞれの利点と不利点を，とが多かったが，元の英文を比較しても，これら 3つくづく再認識させられたのだった。

つの単語の使われ方に明確な区別があるようには見翻訳作業は，本来ならば，全ての業務に精通した受けられなかった。他にも library のように，頻者が行なうのが理想である。今回そのような状況で出語であるにも関わらず，Ex Libris 社が独自の使いはなかったなか，業務やデータについてわかりやす方をしている（「データベース」の意で使用）語もあく説明してくださったプロジェクト室の各モジュー

り，メッセージによっては，どちらの意味で使われル担当およびシステム担当，そして現場の視点からているか，判断しかねるケースもあった。

数々のご意見をお寄せくださった各地区メディアセ

GUI メッセージは，ファイル数が膨大であることンタースタッフの皆さまに感謝したい。と，同一メッセージが複数存在することから，用語の変更要望があった場合，対象となるメッセージを4 おわりに見つけ出すのに時間を必要とした。場合によっては，日本語化の作業に終わりは無い。なぜならば，今複数の同一メッセージ中，実際に使用されているの後も Aleph のバージョンアップが行なわれる度に，がどれであるかを特定するために，可能性のあるエラーメッセージの追加や，場合によっては GUIメッセージに意図的にダミーの文字列を埋め込んでそのものの変更が生じるからである。今回慶應が行出現個所を確認したりもした。

なった日本語化の作業は，あくまでも慶應に Aleph（4）その他の翻訳対象ファイルを導入するために行なわれた作業であって，純粋なキャンパス名や資料区分などのような，GUI 上の意味での Aleph GUI の日本語版としては，土台をプルダウンメニューに表示される選択項目は，各モ作ったに過ぎないと個人的には思っている。今後日ジュールで使用される設定テーブルの値がそのまま本において Aleph ユーザーが増え，この土台を基に反映される。Aleph の導入に伴い，業務フローやコー日本語版 Aleph がより良いものとなっていくことド体系の見直しが行なわれたこともあり，それらのを，強く願うばかりである。

設定テーブルの調整は，各モジュール担当がシステ

29