Open5

OAXAL

hidarumahidaruma

Open Architecture for XML And Localization

http://docs.oasis-open.org/oaxal/V1.0/oaxal-v1.0.html

Open Architecture for XML And LocalizationOAXAL)は、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 Memoryxml:tm)を使うことを示しているのがOAXALの特徴です[1]

xml:tmは他のローカリゼーション周りの規格を先に学んでいないと分かり辛いところがあるので、説明自体は後に回します。

脚注
  1. これは筆者の勉強不足だと思うのですが、Okapi Frameworkはどこでxml:tmを使っているのか分からないんだよな ↩︎

hidarumahidaruma

Internationalization Tag Set(ITS)

https://www.w3.org/TR/its/

Internationalization Tag Set (ITS)は、XML・HTMLに対し、文章用の情報をタグに紐付けて付加するXMLアプリケーションによる標準仕様です。W3Cで勧告されています。

文章用の情報とは、大まかに次のものです;

  • 内部のコンテンツが翻訳可能であるか
  • ブロックレベルのテキスト中に出現する(インラインの)タグか
  • 内部のコンテンツが専門用語を示すタグか

他にも、LinkedDataに使う情報かなどのタグを分類するもの、翻訳者用の追加情報などありますが、先の3種類が判別できればOAXALへの活用が可能です。

translateRule

termRule domainRule

withinTextRule