OmegaTのHTMLファイルフィルターを移行した話

HTMLファイルの翻訳に関して、OmegaTのビルトインフィルターがポンコツな話を旧はてなダイアリー時代にも書いたりしてたんですが*1、ふと思い立ってOkapi Filters Plugin for OmegaTに再チャレンジしたところ、なんとかなったのと、これに付随して以前からやりたいことができたので、自分用にメモっておくお話。

これまでの環境

  • OmegaTにビルトインされているHTMLフィルターを使って訳文を生成(翻訳メモリーもこれで生成しており、GitHubにある全部の翻訳はこれを使い回し)
  • OmegaTの翻訳ファイル生成はなぜかバッチ処理できなかったので、GUIをわざわざ起動して、都度生成
  • PowerShellで翻訳生成文書の前後処理(whatwg.orgからcurlっぽいことをして原HTMLを前処理、うさんくさい後処理もPowerShellで)

OmegaTバッチ処理する

手順が前後するけれども、これはまあ比較的単純で、取扱説明書にあるようにOmegaT コンソールモードで動かせばいいだけの話だったり(単純な話なんだけども、なぜか以前に試したときは動かなかった)。

java -jar OmegaT.jar /path/to/project --mode=console-translate

jarファイルの直後のディレクトリーは、OmegaTのプロジェクトファイルのあるディレクトリーを指定。Windowsであればエクスプローラーでパス名を出せるのでそれをはっつける。My documentみたいにうっかりスペースが含まれている場合は、ダブルクオーテーションでくくるのをお忘れなく。

ちなみに、ディレクトリーの解決の関係で(実際には試してないけれども)、bash on Windows(正確にはWindows Subsystem for Linux)にあるjavaで叩くとコケると思われるので、bashからは

exec cmd.exe /c omegat_run.bat

とでもして、cmd上で走らせている。

フィルターの移行

tmxを移行させる

OmegaTのタグの数え上げがズレる(ビルトインフィルターが0から数え上げるのに対して、Okapiフィルターは1から数え上げる)のと、タグの名前がほぼ全て汎用になる(HTMLのa要素は、ビルトインフィルターでは<a0>になるが、Okapiのフィルターはタグ名がなんであると<g1>のようにgに解決される)。例えば次のように機械的に置換してしまう。

for mark in s a g d e
do
for i in {0..30}
do
    j=$(( $i+1 ))
    sed -i -e 's!\&lt;/${mark}${i}\&gt;!\&lt;/g${j}\&gt;!g' omegat-replaced.tmx
    sed -i -e 's!\&lt;${mark}${i}\&gt;!\&lt;g${j}\&gt;!g' omegat-replaced.tmx
done
done

置換済みのtmxを、OmegaTの翻訳メモリディレクトリー(\tm\auto)に設置すれば、一致した箇所は自動的に食ってくれる(9割方はこの方法で解決できる)。

OmegaTのフィルターをOkapiのフィルターに切り替える設定

グローバルには[設定]→[ファイルフィルター]→[ファイルフィルター]で、ビルトインフィルターのチェックを外してしまえばOkapiのフィルターを使用するようになるが、プロジェクトごとに切り替えることもできる。その場合は、[プロジェクト]→[プロジェクト設定]→[ファイルフィルター]で、[ファイルフィルター設定をプロジェクト専用にする]にチェックを入れた上で、読ませるフィルターを変更すればよい。

Okapiフィルターの要素・属性ルールを変更する(重要)

2019年3月時点では、デフォルトの要素・属性ルールがポンコツ(例えば、mark要素を知らない)なので、Okapi Rainbowを起動して。[Tools]→[Filter configuration...]でHTMLを選択し、[create]でCustom Configurationでokf_html@copy-of-default.fprmを任意のディレクトリーに吐き出させる。吐き出したファイルはテキストエディターで編集可能。

ルールの書き方は、HTML Filter - Okapi Frameworkに記載されているとおり。すでに仕込まれているものを見れば、なんとなくわかる(雑)。

カスタム設定を読ませる

OmegaTのフィルターをOkapiのフィルターに切り替える設定」の画面で、HTML files (Okapi)を選択して、[設定]ボタンを押すと、Okapi Filter Optionsというダイアログが出てくる。"Use the following filter parameters file:"に切り替えて、先ほどの設定ファイルを指定すればよい。ファイルの文法を間違えてプロジェクトが読めなくなってしまったときは、プロジェクトディレクトリーの\omegat\filters.xml中の<filter className="net.sf.okapi.lib.omegat.HTMLFilter" enabled="true">の中にある要素を適当に変えればよい(雑)

HTMLファイルの前処理

Okapiのフィルターのバグ挙動として、

<a href=./>Home</a>

というようなHTML断片を読むと、パースに失敗して出力ファイルがおかしくなる。これを回避するにはあらかじめ

<a href="./">Home</a>

と引用符でくくってしまう。次のようにsedで一括処理してしまう。

grep -l '<a href=./>' ./dev/*.html | xargs sed -i -e 's!<a href=./>!<a href="./">!g'

フィルター間のdiffをとる

精製ファイルを目視で眺めても結構抜けがあったりするけれども、diffでハイライトさせるとよりわかりやすくはなる。
HTML Diff servicePerlスクリプトCVS log for 2009/htmldiff/htmldiff.plから入手できるので、ローカルでperlを叩けばOK。OmegaTビルトインフィルターは原HTMLに関わらず特定の文字列(たとえば>)を実体参照に勝手に置換してしまうようなので、diffを取る前に置換して比較するとよい。

grep -l '&gt;' *.html | xargs sed -i -e 's!&gt;!>!g'

みたいな感じで。

とまあ、ざっくりとこんな感じかなと。
翻訳をはじめた当時は、Windows Subsystem for Linuxがなく、PowerShellという選択肢がベターではあった(のでPowerShellを使っていた)けれども、そんなに真面目にやる気がなく、Linuxにほんのちょっぴり馴染みがあるので、シェルスクリプトで処理できるの個人的には結構楽ですね。

JIS X 8341-3:2016は誰が作ったのか

あるいは、W3C WCAG 2.0とJIS X 8341-3の関係について。なんか某所でJIS X 8341-3:2016をW3Cが作ったことになっていたけれども、そうじゃないんだというお話です。

短い答え

W3Cが英語でW3C仕様として発行し、それをウェブアクセシビリティ基盤委員会が日本語に訳してJISにしました。

ものすごく長い答え

誤解されることがあるのですが、JIS X 8341-3:2016そのものをW3Cが作ったわけではありません。「短い答え」は圧縮した回答であって、標準規格にまつわるあれやこれやを踏まえると実は正確ではないのですが、みかけの状態としては誤りではないため、このような答えになっています。
では、その標準策定にまつわるあれやこれやというのは何なのか、「短い答え」はどうやって導き出されたのか、というのをだらだらと説明するのが、この「ものすごく長い答え」の趣旨になります。

W3Cの概略とWCAGの歴史

ウェブ業界の人にはなじみのあるだろうW3Cという標準化団体は、おもにウェブに関する技術文書を発行しています。著名な仕様としてはマークアップ言語であるHTML*1XMLマークアップ言語の見栄えを制御するCSSなどが挙げられます。このエントリーで取り上げるWCAGもW3Cが発行しました。
WCAGはWeb Content Accessibility Guidelinesの頭文字を取ったもので、その名のとおりウェブコンテンツのアクセシビリティガイドラインです。このガイドラインに従うことで、ウェブコンテンツのアクセシビリティを向上させることができる、というものです。
WCAGの歴史としては、1999年にWCAG 1.0という最初のガイドラインが、2008年にWCAG 1.0を大幅に改良したWCAG 2.0が、2018年にWCAG 2.0に追記をしたWCAG 2.1が発行されました。

W3Cの仕様策定プロセス

W3CはTechnical Reportとして、大別して2種類の文書を発行しています。1つはW3C Recommendation(日本語ではW3C勧告と呼ばれる)技術標準、もう1つはW3C Working Group Note(日本語ではW3Cワーキンググループノートなどと呼ばれる)技術参考情報です。前者は、策定中の文書も含めてW3C Specification(日本語ではW3C仕様など)とも呼ばれ、ウェブの技術標準にあたります。後者がW3C勧告の参考・補足情報を提供したもの、またはW3C勧告を目指したもののさまざまな事情により策定を断念したものという位置付けになります。
Technical ReportはW3C Process Documentと呼ばれる文書に則って、いくつかの草案段階を踏まえてW3C勧告は策定されます。もうちょっとつっこんだ日本語の説明については、W3C勧告プロセスの概要を参照してください。
W3Cでは、Working Groupという内部組織で、各分野についての仕様の策定が行われます。例えばCSSであればCSS Working Groupが、WCAGであればAccessibility Guideline Working Goup(WCAG 2.0まではWCAG Working Group)が策定しています。W3C Process Documentに基づいて、各Working Groupの中で議論して作成したものを、W3Cはウェブサイトに掲載して発行します。

JISとJIS X 8341-3の歴史

JISというのは日本工業規格の英語の頭文字を取ったもの*2で、日本の公的な標準です。比較的身近だろう例を考えてみると、JISマークのついた定規を見たことがあるかもしれませんし、洋服についている洗濯表示の記号が少し前に変わっていて頭を抱えたという人もいるかと思います。あるいは、A4やB5といったの紙の大きさもJISできっちり決まっています。こんな塩梅で、あんまり意識しなくても身近にJISが潜んでいたりします。

ところで、日本の法令が技術的な基準への適合を強制する場合に、その基準としてJISが採用されます。また、国や地方公共団体に対しては、強制規格に準じた性格を持ちます。言い換えると、国や地方公共団体が、JISに関連する製品を購入する仕様を定めるとき、JISを尊重するように法律で決められています*3。つまるところ、ウェブサイトを国や地方公共団体が発注するときに、ウェブアクセシビリティの要求項目が組み入れられる場合、JIS X8341-3:2016が参照されますが、これは法律でそうなっているから、と言えます。

JIS X8341-3の歴史としては、2004年に制定され、2010年と2016年に2回改正がされました。2004年版はWCAG 1.0等を参考に制定され、2010年版はWCAG 2.0を取り込む形で改正されました。2016年版はWCAG 2.0と技術的内容、構成、文言が一致した規格として改正されました。

JISの制定プロセス

JISは工業標準化法という法律によって定義され、関連する政令によってJISは制定されます。図で説明された制定プロセスは、日本工業標準調査会:JISの制定等のプロセス<図の説明>を参照してください。
JIS X 8341-3:2016の場合は、ウェブアクセシビリティ基盤委員会(WAIC)と日本規格協会JSA)が改正の申出をし、日本工業調査会(JISC)が審議し、経済産業大臣が改正した日本工業規格です。

W3CとJISの関係

これまでに、W3CとJISについて説明してきましたが、端的に言ってしまうと直接の関係ありません。W3Cは英語の文書しか作りませんし、JISは日本のための規格なので、日本語で書かれます(英訳版も存在することがあります。実際JIS X 8341-3の2004年版と2010年版は英訳したものが存在しました)。しかしながら、W3C勧告とJISの両者を結びつけるものが存在します。それがISOの規格です。

ISOとその組織概略

ウェブ業界でISOになじみのある人がどのくらいいるのかは分かりませんが、ISO/IEC 15445(いわゆるISO-HTML)は知っている人は知っている規格番号でしょうか。ISO/IEC 10646(≒Unicode)だと知っている人はもう少し多いかもしれません。街中や書店の店頭だと、ISO 9000シリーズだとかISO 14000シリーズという言葉を見かけたことがあるかもしれません。
さて、日本語では国際標準化機構と呼ばれるこの標準化団体は、各国の国家標準化団体で構成されます。日本からは、日本工業規格調査会(JISC)が会員として参加しています。
ISOは、多数の専門委員会(Technical Committee)が産業分野ごとにおかれ、専門委員会の中で議論がされます。かつてコンピュータや情報分野の専門委員会がISOの中に置かれていましたが、IEC(国際電気標準会議)というISOとは別の、電気電子分野に関する標準化団体と標準化の範囲が重複するために、IT関連について現在ではISOとIECの合同で委員会が置かれています。これはISO/IEC JTC1と呼ばれ、ウェブ技術もここで検討されます。

ISOの策定プロセスの概略

各国の会員組織が議論して決めるという組織の性質上、ISOの規格が制定されるまでは、複雑なプロセスに則って、段階を経た規格案が作成されます。複雑なプロセスの性質上、制定されるまでに必然的に時間がかかります。
ここでは詳細は触れませんが、公式にはISO/IEC Directives, Part 1という文書で規定されています。日本語の説明はJISCにあるISO規格の制定手順が参考になります。
ところで、IT技術は進歩が早い業界と一般に言われます。これは見方を変えると、従来のISO規格の制定方法だと時間がかかりすぎてしまうわけです。これを克服する1つの方法として、ISOの制定プロセスを短縮できるファストトラックという制度があります。1つの例としては、XMLの応用であるOffice Open XMLMS Officeの保存形式)はこの制度を利用して作成されました。
ファストトラックとは別に、ISO/IEC JTC1ではPAS Submitterという規格の転換プロセスを用意しています。これは、JTC1が認定したISO/IECの外部の標準化機関が策定した仕様類を、ISO/IECの規格案として取り込み、ファストトラックのようにISO内部の一部プロセスをスキップして国際規格に取り込むものです。W3CはISOにPAS Submitterとして認定されており、WCAG 2.0はこのプロセスを利用して2012年にISO/IEC 40500:2012となりました。ISO/IEC 40500:2012はW3C勧告であるWCAG 2.0そのものです。

ISOとJISの関係

上で書いたように、JISを審議するJISCがISOのメンバーとして参加しているほかに、JISは原則として、ISOにある規格はISOにあわせなければならない、というルールがあります。これは、貿易の技術的障害に関する協定と呼ばれる国際条約により、国家規格を国際規格と整合したものでなければならない、と定められています。ざっくばらんに言えば、各国でばらばらな規格で工業製品などを作られると、作るのにも使うのにも困るので、国際規格に統一しましょう、という趣旨です。
JIS X 8341-3の2016年の改正は、このルールに則ってなされたものです。

W3CとISOの関係

前述のように、W3CはISO/IEC JTC1のPAS Submitterであり、これを利用して2008年のWCAG 2.0勧告を2012年にISO化しました。これとは別に、規格開発にあたってISOの委員会と連携を行うリエゾンの関係でもあります*4

長い答えを踏まえた短めのW3C WCAG 2.0とJIS X 8341-3の関係

とまあ、「長い答え」としてはこんな感じです。これを踏まえて短くまとめると、次のような感じでしょうか。
2008年のW3C WCAG2.0勧告がISOに取り込まれ、ISO/IEC 40500:2012として発行されました。これを受けて、それまで独自にWCAGを参照していたJIS X 8341-3は、ISO/IEC 40500:2012の一致規格として2016年に改正されました。JIS X 8341-3:2016のJIS原案はウェブアクセシビリティ基盤委員会が作成しました。W3C WCAG2.0とJIS X 8341-3:2016は、技術的に同一の内容です。

おわりに

W3CとJISとISOについて、規格類の策定プロセスと、その関係についてちょっぴり踏み込みつつ、W3C WCAG2.0勧告とJIS X 8341-3の関係の説明を試みました。ブログにまとめた都合上、詳細について正確な解説をせずに端折っている部分があります。というか、ぶっちゃけ調べて書いただけなので、誤りがある箇所があり得ます。また、国会図書館に行きそびれて、2004年版と2010年版の規格票を見ずに書きいたことを白状します。正確な説明については、各標準化団体が発行している文書などをあたってください。

本文中に示さなかったその他参考文献

*1:実はHTMLに関してはもはやW3Cが策定している状況でもないのですが、それは一旦脇に置いておきます

*2:今年の7月から日本産業標準という名前に変わりますが、JISという略称はそのままです http://www.meti.go.jp/policy/economy/hyojun/JISho.html

*3:工業標準化法第67条

*4:余談ですが、このリエゾンの関係を読み解けば、WCAG 2.1がもしISOで審議される場合に、ISO/IEC JTC1/SC35/WG6が引き取ることが推測できます。