タグ別アーカイブ: HTML

DeepLによるHTML翻訳でタグが正しく取り扱われるか?

日本語の文章を英語に翻訳するためにツールとして、機械翻訳がかなりいいレベルまで来ているのは周知のとおりです。では、HTMLでタグ付けされたWebページの翻訳にも機械翻訳を使えるでしょうか?

HTMLファイル機械翻訳の課題

日本語HTMLファイルは大きくわけるとテキストコンテンツと画像やマークアップ(タグなど)から構成されます。

タグにはいろいろな種類があります[注1]。メタ情報を表すタグ、見出し、段落、箇条書き、表などのブロックの区別を表すタグ、強調、アンダーライン、上付き・下付きなどテキストの意味合いを表すインラインタグ、リンクや画像を埋め込むタグ、などです。

WebページのレイアウトはCSSで指定します。このため多くのタグに、CSSによるレイアウトを制御するための属性が付加されます。また、HTMLファイル内にはブラウザで表示する際のダイナミックな動作を表現するためにJavaScriptが埋め込まれます。このためHTMLファイルは、コンテントのテキストと比べてかなり複雑になり、通常はマークアップ作業に多大な時間がかかります。

機械翻訳のシステムでHTMLファイルを日本語から英語に翻訳するとき、(1)テキストコンテンツの翻訳の品質に関わる課題と、(2)タグの扱いが適切かどうかという課題があります。

タグの扱いについての要件

ここでは、主にタグの取り扱いを考えてみます。まず、タグの扱いは基本的には次の条件を満たす必要があります。

1.タグ自体は翻訳せず、タグのツリー構造は保持されなければならない。つまりタグの順序が変更されないこと。開始タグと終了タグの対が保持されること。タグの親子関係(入れ子関係)が崩れないことなどが満たされること。
2.開始タグには属性と属性値が付随することがあります。属性は翻訳せず、属性値は多くの場合、翻訳しない方が望ましいが、翻訳してほしいこともある。

日本語のHTMLファイルを機械翻訳した結果、タグのツリー構造が壊れてしまったり、マークアップが不適切になってしまうと、機械翻訳の出力として得られたHTMLファイルのタグ付けを修正する作業が必要になります。もし、タグの構造が完全に破壊されてしまうと、プレーンテキストにゼロからタグ付け作業をする方が手間が少ないということになります。

特に、インラインタグは翻訳テキスト中に混在するのでタグのツリー構造を維持するのが難しい場合がありそうです。そこで機械翻訳システムがテキストコンテントとタグを分離してうまく扱えるかどうかは詳しく調べてみる必要があります。

機械翻訳のHTMLファイル形式サポート

機械翻訳システムによってはタグでマークアップしたテキストを翻訳対象にできないことがあります。ここで使用するDeepLは、Free版ではHTML形式ファイルを扱えません。一方、Pro版とAPI版がHTMLファイル形式を翻訳対象としてサポートしています。

Which file formats can I translate?

DeepLによる日本語HTMLファイルの英語への翻訳例

そこで、今回、DeepLでHTMLを翻訳したときタグが正しく扱われるかを調べてみました。翻訳の対象としたのは、Formatter V7.4(開発中)の日本語HTMLマニュアル(XSL/CSS拡張)です。

Formatterのマニュアルは、日本語と英語版のWebヘルプとして作成されています。V7.3(現行バージョン)についてはこちらからご覧いただけます。現在、翻訳は社内の専門スタッフが行っており、機械翻訳は使っていません。
Antenna House Formatter V7 日本語版マニュアル
Antenna House Formatter V7 日本語版マニュアル・XSL/CSS拡張
Antenna House Formatter V7 英語版マニュアル
Antenna House Formatter V7 英語版マニュアル・XSL/CSS Extensions

DeepL翻訳結果・第一印象

日本語のHTMLをDeepLで英語に翻訳翻訳した結果はいちおうHTMLなのでブラウザで表示できます。最初に、翻訳元の日本語HTMLファイルと、DeepLで翻訳した英語HTMLファイルのブラウザ表示を比較してみます。

1)目次部分

翻訳元日本語目次(左)、翻訳結果の目次(右)

2)見出し、本文や表

見出し、本文(太字)、リンク、表

3)表と箇条書き

表と箇条書き

こうしてみますと、ブラウザで表示して比較できるレベルでタグが付いているようです。ただし、ブラウザはHTMLファイルのタグが正しくなくても表示できるように作られているので、ブラウザで表示できるからと言って、タグが完全に適切に付けられているとは言い切れません。

また、翻訳された内容を詳しく見ると、細かい点に問題が見つかります。

では、HTMLタグがどの程度まで適切に設定されているでしょうか? これを確認するにはHTMLファイルのタグを詳細にチェックする作業が必要になります。そこで、次回は、DeepLのHTML翻訳結果のタグ付けについて詳細に検討してみることにします。

[注1]
HTMLのタグの種類やタグ付けの規則については次の標準仕様で規定されています。
HTML Living Standard




瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集


アウトライナー
PDFを解析して しおり・目次を自動生成

書籍のHTML版の構造を考える(OOXML入門第2版)

12/07に「『Office Open XML Formats入門 第2版』制作報告」のウェビナーを行いました。ウェビナーで言及したように、『Office Open XML Formats入門 第2版』はHTML版も制作中です。

編集用XMLであるSimpleDoc(の改造版)はほぼHTMLの文法なので基本的にはそのままです。
とはいえ、そのままで出せるかというとそうでもなく、「表示媒体の違い」へ意識を向ける必要があります。本記事ではその辺りについて「こんなことを考えながら作っています」という話です。

形式

まず、HTMLとしてはHTML5、もといLiving Standardに合わせています。他社コンテンツを制作するような場合に比べれば更新の自由が利きますし、セマンティックな語彙が多い方が嬉しいですね。変換自体にはXSLT 3.0を利用しています。

スタイル設定

SCSSで大本を記述した後、CSSに変換したものをlinkの読み込み対象にしています。あるページ特有のスタイルというものは無かったため「_color.scss」「_header.scss」、「_footer.scss」これらを読み込む「common.scss」のようになっています。

ページ分割とナビゲーション

まずページ分割単位の決定。「最終的に1ページのHTMLファイルに収める」というのはそれなりの文量のある書籍では現実的ではありません(動的に内容を取得するのであればそういった方法もあるでしょう)。今回は「章単位でフォルダーを分け、節単位でファイルを分ける」ということにしました。
余談として、DITAではDITA-OT標準のHTML出力を行うとトピックごとにページが分けられます。書籍の形態を重視する場合はこのトピック単位というのは個人的にはやや扱いづらいものであったりします。

ナビゲーションの追加について。特に静的なページとして用意する場合、次の箇所へ遷移する方法の確保は重要です。HTML版用に新たに考えるべき項目としては「常に目次をページ内に配置する」「前後の箇所へのリンクを配置する」「検索用のページを用意する」といったことが挙げられます。

「常に目次をページ内に配置する」については「目次へのリンクを各ページに配置する」で濁してあります。ページごとに記述量が増えて若干デバッグがしづらくなるためです。全ページに目次を配置した場合も、ファイルサイズとしては誤差でしょう。「iframeタグで目次ページを表示させる」ことも可能ですが、今回はリンクを選択しました。

コンテンツの配置レイアウト

body/headerに章題と章トップページ・目次ページ・前後ページへのリンク、body/footerに前後ページへのリンク、body/main内にそのページのコンテンツを配置しました。
書籍と構成は変わるものの「常に(画面上という意味でなく)表示されて欲しい情報」とコンテンツとして欲しい情報といった整理を行うことに変わりはありません。

書籍版と見せ方を変えるもの

Webブラウザーでは紙の本ではできない操作が可能です。今回、次のような変更をしています。

  • コードブロックにoverflow:scrollを設定。
  • h3のsection内容をdetailsタグでアコーディオン表示設定。
  • 画像にwidth:100%を指定。

記事内容の主題といっても良い箇所だと思うんですが、3行で終わってしまいました。

相互参照、リンク

これは「できるならやった方が良い」という話です。HTML版用に新たに用意するにはコストが高く、やるのであればHTML版に関係なく取り組む価値があります。
書籍内の単語や索引、図参照などをハイパーリンクとして設定することについて、元原稿であまり積極的に設定していなかったためにほぼ見送りました。PDF用にリンク用の機構をしっかり準備、活用していれば流用できただけに惜しいです。

メタデータ

「メタデータ、head内をどこまで用意するか」といった話があります。「この場所(弊社Webサイト)にこのコンテンツがあることを知っている」方に対して公開する向きが強いため、ひとまず先送りにできるだろうということがあげられます。
JSON-LDによるメタ情報の追加やサーチエンジン巡回用のRobots.txt、といったものですね。

最低限の項目としてtitle、言語、エンコーディング、viewportの初期値といったものは設定しました。これらは文字化けやモバイル端末での表示性確保として最低限設定すべき箇所でしょう。

OGPについてはある程度用意した方がSNS上でのリンク表示が見栄えするのである程度は確保したいので悩ましいところです。

作業が完了していないこともあり今回はこの辺りで。HTML版(、そして販売準備中のプリントオンデマンド版も)の完成まで少しだけお待ちください。

参考資料




瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集


アウトライナー
PDFを解析して しおり・目次を自動生成

AH FormatterでXSL-FO 2.0 仕様DraftのWebページをPDF化してみる

業務を行っていると、W3Cで公開されている仕様を確認しにいくこと、例えばXSL-FO 2.0のDraft[1]を確認しにいくことがあったりなかったりします。
Webページの利点の1つはスクロール操作によって文書の目的の位置へいけることですが(もちろんそうでない作りのWebページもあります)、手元の電子ペーパー端末でページをめくるように読みたい場合もあります。
「WebページのURLを打ち込むだけでそこそこ読めるPDFを出力してほしい」、そんなときにもCSS組版が可能なお手持ちのAntenna House (CSS) Formatterが利用できます。

AH Formatterでファイルを読み込む際、通常はファイルパスを指定するかと思います(GUIではドラッグ&ドロップも可能です)。しかし、ここにWebページのURLを指定することもできます。マニュアルにも記載してありますね。「組版種別」によって、AH FormatterのデフォルトCSSを使用する設定、元のHTMLのCSSを利用するなど違いがあるので、マニュアルを確認してください[2]。

Windowsの場合、AH Formatterをインストールしたフォルダにhtml.cssがあります。これがHTMLファイルを読み込んだときにAH Formatterのデフォルトとして適用されるCSSです。
今回は「HTML」を指定しました。

全体的な文字サイズやページサイズなどを「組版オプション」で設定してみます。


XSLT2.0の仕様[3]を、ページサイズをJISB5、本文14ptとしてみたところ、673ページ程度になりました。

JIS B5サイズのPDFでXSLT2.0 仕様出力

記事冒頭で「例えば~」とXSL-FO2.0の話題を振っておきながらFOではなくXSLT2.0で例を出しているのは、XSL-FO2.0のドラフトだと1200ページ超え(JISB5、本文14pt程度)となり、GUIでプレビューを表示しながら操作をするには手元のマシンだと厳しいためです[4]。CUIで組版する分には問題ありません。

JIS B5サイズのPDFでXSL 2.0 Draftを出力

今回PDF出力してみたWebページの場合ですと、ソースコードや巨大な画像ではページサイズに収まるように表示できていません。元がリフロー型のWebページなので、デフォルトのCSSでは少し無理があったようです。とはいえ、手軽にそこそこ見やすいPDFを得ることができました。

Antenna House Formatterの評価版は、こちらのページからお申込みいただけます。
AH Formatter 評価版のお申し込み

CSSでのページメディアの印刷に興味がある方へ、アンテナハウスでは『CSSページ組版入門』という書籍を発行しています。

  1. [1] Extensible Stylesheet Language (XSL) Version 2.0
    W3C Working Draft 17 January 2012
  2. [2] ドラッグ&ドロップ組版 – Antenna House Formatter V7 マニュアル グラフィカルユーザインターフェイス
  3. [3] XSL Transformations (XSLT) Version 2.0
  4. [4] ページ数上限自体は変更可能です。 制限事項 – Antenna House Formatter V7 マニュアル グラフィカルユーザインターフェイス

関連記事

  1. AH Formatter の CSS組版例「MathML 3.0 2nd Edition」

Antenna House Formatter V7XSL-FO/CSSスタイルシートにより、XMLとHTMLをサーバー上で高速にPDFに変換!




瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識

DITAとしてのMDITA

前回の記事で、MDITAで使えるMarkdown(派生)の記法について紹介しました。
しかし、MDITAの特徴は「Markdownの文法でトピック指向ライティングしたものをDITAに取り込める」ことに限りません。
DITAの機能(の一部)をMDITAから使うことができるのです。
とはいっても、Extended ProfileでHDITA(HTML5)の記法を使用してのもので、
「MDITAの機能」と言っていいのかは微妙なところですが。
前回の記事内容ではMarkdownとしてMDITAを各種ツールで扱うことができましたが、
今回紹介する機能を使用して期待した出力結果を得るには、
DITAのパブリッシングエンジン[1][2]を使用する必要があります。

conrefやkeyrefでは、リンクのURLやファイルのバージョンなど
変更される可能性がある(そして文書自体に変化は無い)要素の
文書中には参照を残しておき、その内容を別ファイルに
置くことができます。動作のイメージ図は「DITA超入門」[2]をご覽ください。

<!-- about.md -->
AH Formatterの最新版は<span data-conref="latest.dita#ver" />です。
<!-- latest.dita -->
<ph id="ver">7.0</ph>では...

パブリッシュした結果では次のように表示されます。

AH Formatterの最新版は7.0です。

また、出力に表示する要素をフィルタできる機能も限定的に使用可能です。
data-props属性に値を指定することで、トピック側の準備は完了です。


...XSL-FOでは上のように記述します。
<p data-props="notxslfo">もしCSS組版なら......</p>

フィルタの動作を記述する.ditavalファイルの中身はXMLで記述する必要があります。


<!-- ifcss.ditaval -->
<prop att="data-props" action="exclude" val="notxslfo" />

パブリッシュした結果では

...XSL-FOでは上のように記述します。

と、excludeした値が消えています。

これらの機能は、HDITAではdata-conrefdata-keyref属性にidを指定することで利用できます。

HDITAにはフレーズ要素<ph>が無いので、
単語などのkeyrefconrefでの置き換えには
<span>を用います。

LwDITAについてのより詳細な情報は、OASISによるイントロダクションのページ[4]や、前回の記事などをご覧ください。
次回は、MDITAからXDITA、DITAへの変換と編集についてを予定しています。

参考

  1. [1] DITA入門 パブリッシング
  2. [2] DITA-OT
  3. [3] DITA超入門 – アンテナハウス
  4. [4] Lightweight DITA: An Introduction Version 1.0

  5. DITA/XML - Antenna House

    関連記事

    1. XMLエディタで始めるリッチなMarkdown入門?
    2. MDITA(LwDITA uses Markdown)の書き方
    3. Markdown DITAとMDITA
    4. XMLをMarkdownに変換することについて



瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識