2006年1月28日、サンの用賀オフィスにて、日本Linux協会のOpen Source Documentation Meetingによる「翻訳支援環境に関するセミナー」が開催されました。これは、昨年12月に開催されたセミナーの続編です。すでに先進的なユーザがこのツールの試用を始めており、セミナーでは多くの質問が寄せられました。

翻訳メモリで、どのくらい既存の訳文を再利用できますか。

翻訳対象や、ソフトの機能アップ状況によって違ってきます。例えば、Solarisのバグフィックスリリースで新機能がない場合、既訳のドキュメントを絞り込むと、80%ほど再利用できました。

翻訳支援ツールの鍵は、翻訳メモリ情報をどのくらい構築できるか、という点にあると思います。既存の英文／訳文を簡単に翻訳メモリ情報に取り込む方法はありませんか。

現在のところ、そのような機能はありません。ただし、英文と訳文のペアがきちんと対応したデータになっていれば、スクリプトなどで簡単に取り込めると思います。翻訳メモリ情報(以下、miniTM)はTMXというファイル形式で、インポート／エクスポートできます。これは、それほど複雑なファイル形式ではありません。オープンソースでは無いですが、CSVファイルをTMXに変換するツールもあります。

あるプロジェクトで翻訳メモリ (miniTM) を作った場合、別のプロジェクトでそのメモリを使うことはできますか。また、別の人が作った miniTM を共有することはできますか。

前者の場合は、同じプロジェクト名を指定すれば共有できます。後者の場合は、「Tools」->「Merge Mini-TMs」メニューで、自分の miniTM と別の人の miniTM をマージすれば可能です。miniTM は、ホームの下の .xliffeditor/mini-tm の下に作られます。

翻訳メモリ情報の標準であるTMXに対応していますか。

TMX 1.3 のインポート/エクスポートに対応しています。

OLTでは、翻訳単位であるセグメントをピリオド「.」で分けますが、これが実際の区切りと対応していない場合があります。たとえば、タグで囲まれていない部分に「.i」という拡張子があった場合、「i」の前後でセグメントが分かれてしまいます。このような場合は、どうすればいいでしょうか。

ファイル名がタグで囲まれていればセグメントの区切りとは認識しませんが、そうでないと仕様上、ピリオドの前後でセグメントが分かれてしまいます。この仕様については今後改善する予定です。現状でこの問題が発生した場合は、2 つに分割されたセグメントのうち分量が多い方に訳文を入力し、少ない方は空にすることでより多くの内容を再利用する、というテクニックを使用することができます。

サンの翻訳メモリDBを、公開する予定はありませんか。

今後、やりたいと考えています。ただし、データベースのライセンスについては、議論が必要かもしれません。

現在のOLTは、メニューなどが英語になっています。これを多言語化（日本語化）する予定はありますか。

OLTは、頻繁にバージョンアップしており、サン社内でも使用しています。そのため、日本語化のために、すぐに使えないのでは仕事に差し支えがあります。もちろん、コミュニティで多言語化してくれるのは歓迎します。XLIFF Filterについては、フランス語版などが提供されています。

XLZファイルは、どのようなファイルでしょうか。

XLIFFファイルは、翻訳支援ツールの中間ファイルのための標準ですが、コンテンツだけでブロックなどの外部情報（スケルトン）を持つことができません。そこで、スケルトンを追加し、Zip圧縮したのがXLZファイルです。

翻訳作業では、その文が出てくる場所によって意味が変わることがあります。OLTでは、それをコメントやアノテーションとして扱えますか。

XLIFF 内ならコメントを残せます。つまり、OLT Editor 上ではコメントを確認できます。しかし、生成した TMX ファイルおよび Backconvert (元の形式への変換) で生成した翻訳後のファイルには、コメントは残りません。

FrameMakerやnroffには対応していますか。

FrameMaker については現在テスト中です。nroff については対応する予定はありません。

※著者のタイトル、所属等は、執筆当時のものであり、現在と異なる場合があります。
また、日本サン・ユーザ・グループは2007年6月をもって休会しております。

ご意見・ご感想をお聞かせください

この記事は参考になりましたか？ 参考にならない   参考になった   非常に参考になった コメントがございましたらご記入ください

ページ先頭へ