Open2022/10/11にコメント追加5

OAXAL

hidaruma 2022/10/11に更新

Open Architecture for XML And Localization

Open Architecture for XML And Localization （OAXAL）は、XMLによるオーサリング・翻訳のエコシステムです。アーキテクチャ仕様であって実装そのものではありません。筆者が「こんなのがあるのか！」と感激した2021年にOASISのTCが終了してしまったため、誰もその話していない状態です。とはいえ、代替規格がある訳でもなし、ローカリゼーション周りの規格は結構保守ステートなので暫くは不都合は生じないでしょう。

ドキュメント、翻訳用の規格の多くはXMLアプリケーションとして標準仕様となっています。XMLアプリケーションはそれぞれ妥当なXMLですから、可搬性が高く、アプリケーション間・クライアント-作業者間の交換形式としてある程度の地位があります。

扨、扱うのがドキュメントであるとき、そこそこの頻度で直面するのが翻訳の問題です。翻訳元と翻訳先という関係性が生じることで、考えるべきことが結構増えます。ざっくり挙げると、次のようなものです；

ドキュメント上の対応関係
- 専門語彙・表現
- 言語・用字によるテキスト進行方向の差異
- 言語・用語による区切り方（セグメンテーション）の差異
ドキュメントのリビジョンによる差分
翻訳用テキストの抽出・マイグレーション
翻訳作業量の見積り

これらを解決する方法を考えます。先にこんなことを書きました。

ドキュメント、翻訳用の規格の多くはXMLアプリケーションとして標準仕様となっています。

則ち、それぞれの標準仕様がXMLのルールを守っていて、どんな語彙を使って書かれているかが分かっているということです。とはいえ、それぞれが独立規格と言えるものですから、なんとなくXSLTで変換してみたとはいきません。
例えばDITAにはローカリゼーション用に@translateや@dirが存在します（@xml:langも）。しかしこれらのプロパティが翻訳が望まれない可能性が高い<codeblock>に書かれていることはほぼないでしょう。「codeblockを翻訳されたいワケがないだろう」というのが基本で、「ここは翻訳してほしいという場合にローカリゼーション用のプロパティを記述する」といった運用になります。
ここで「どの語彙は翻訳して欲しいのか」が分かっていれば、人間が一々チェックせずとも機械的に置き換えが可能となります。「<p>は翻訳対象、<pre>は無視する、ただし@translate="yes"があったら翻訳対象」というルールがあればいいんですね。そこで「あるのでこの標準仕様ITSを使ってください」というのが非常にざっくりとしたOAXALで定めているアーキテクチャ仕様となります。
もう少しだけ加えるならば、そうした標準仕様同士の橋渡しとして、XML Translation Memory（xml:tm）を使うことを示しているのがOAXALの特徴です^[1]。