ウェブ関連仕様 日本語訳

日本語訳ページ一覧

• 基盤／その他 ¶
  • Character Model for the World Wide Web 1.0: Fundamentals （ Web のための文字モデル）
  • Infra 標準 （各種仕様に共通して利用される基礎的な句／用語／データ型／規定）
  • Web IDL 仕様 （ Web プラットフォーム API 定義言語）
  • DOM 標準 （ “DOM4” — 文書オブジェクトモデル API ）
  • DOM Parsing and Serialization （ innerHTML, outerHTML, insertAdjacentHTML, DOM の直列化などの API ）
  • URL 標準 （ URL 構文を完全に予測可能かつ相互運用可能なものにする）
  • Encoding 標準 （種々の符号化法による文字列の符号化／復号 処理）
  • Fetch 標準 （リソース取得のための包括的かつ基盤的な処理モデル）
  • Writing Promise-Using Specifications （ promise を利用する仕様の書き方（読み方））
  • Streams 標準 （ストリーム処理のための統一的な構成部品）
  • Worklets （ CSS, Audio などのカスタム具現化スクリプト用の worker 環境 ）
  • Console （デバッグ用コンソール API ）
• WHATWG HTML 標準（ “HTML5” ） ¶
  • 索引など ¶
    • Index （要素／属性 索引）
    • Index （イベント／インタフェース／MIME 型 索引）
    • Named character references （すべての有名文字参照 一覧）
    • Dependencies （ HTML 仕様が依拠する外部仕様により定義される用語の一覧）
    • References （参照文献）
    • （未訳） Table of Contents （目次）
  • （未訳） Introduction （序論） （他サイト訳）
  • 共通基盤（ Common infrastructure ） ¶
    • Terminology （ 共通的に利用される用語, 適合性など）, Dependencies （ 外部仕様により定義される用語）
    • Common microsyntaxes （共通の小構文 — 属性値などに与える数値や日時などの構文）
    • URLs ／ Fetching resources （ URL と fetch の HTML における取り扱い）
    • Common DOM interfaces （ IDL 属性による内容属性の反映法，旧来のコレクション系インタフェースなど）
    • Safe passing of structured data （有構造データを転送するための直列化と復元）
  • HTML DOM と HTML 要素 ¶
    • Semantics, structure, and APIs of HTML documents （文書, 要素, 要素の内容モデル, どの要素にも利用できる内容属性）
    • 意味論を与える要素
      • The document element ／ Document metadata （ html 要素 ／ 文書メタデータ — title, link, meta 要素など）
      • Sections （セクションと見出しを成す要素 — section, article, nav, h1 要素など）
      • Grouping content （内容をグループにまとめる要素 — リスト類, main, div, p, 要素など）
      • Text-level semantics （テキストを構成する要素 — a, dfn, q, em 要素など）
      • Links （リンク関係性 — link, a, area 要素に可能な各種オプション）
      • Edits （編集を表現する要素 — ins, del 要素）
    • 埋め込み内容
      • Images 他 （画像関連の要素 — picture, source, img 要素, および 画像マップ — map, area 要素）
      • iframe, embed, object, param 要素
      • video, audio, track 要素 （動画／音声メディア関連の要素）
    • テーブル
      • Tabular data （テーブルを構成する要素, その処理モデル）
    • フォーム用
      • Forms — Intoroduction （フォームの作り方）
      • The input element （ input 要素）
      • Forms （フォーム用の要素） （ input 以外の各種フォームコントロール — form, button, select 要素など）
      • Forms （共通） （基盤, 各種属性, API, 拘束と検証, 提出, リセット）
        • Autofill （入力欄を自動的に埋める）
    • 対話的な要素
      • Interactive elements （ details, summary, dialog 要素, コマンド）
    • スクリプト用
      • Scripting （ script, noscript, template, slot 要素）
      • （未訳） The canvas element （ canvas 要素） （他サイト訳）
      • Custom elements （カスタム要素）
      • （未訳） Common idioms without dedicated elements （他サイト訳）
      • Matching HTML elements using selectors and CSS （ HTML の UI 要素を対象にする動的 CSS 疑似クラス）
  • （未訳） Microdata （他サイト訳）
  • 利用者対話（ User interaction ）
    • User interaction （ hidden 属性, フォーカス処理, アクセスキー, 編集）
    • Drag and drop （ドラッグ＆ドロップ）
  • ページの読み込み／ナビゲーション（ Loading Web pages ） ¶
    • Browsing context （閲覧文脈）
    • Window object （ Window, WindowProxy オブジェクト）
    • Origin, Sandboxing （生成元, サンドボックス）
    • Session history and navigation （セッション履歴とその辿り方, Location オブジェクト）
    • Browsing the Web （ナビゲーション）
    • （未訳） Offline Web applications （アプリキャッシュ） （他サイト訳）
    • 7.2 節, 7.4 節, 7.7.4 節 （ Window, WindowProxy, Location オブジェクト関連）
  • Web application APIs ¶
    • Scripting （ HTML におけるスクリプト／イベントループ／イベントハンドラの処理モデル）
    • Web application APIs （ Window, Worker で利用できる大域的 API ）
    • Dynamic markup insertion （ 動的マークアップ挿入 — document.open() ／ document.write() など）
    • System state and capabilities （ Navigator オブジェクト — 未知のスキーム／内容型に対するカスタムハンドラ, プラグインなど）
  • メッセージ通信 ¶
    • Communication （文書間の／チャンネルを介したメッセージ通信，ブロードキャスト）
    • Server-sent events （サーバからのメッセージ通信）
    • WebSocket （ WebSocket プロトコル用の API ）
  • Web Workers （スレッド処理 ／ ページ間スレッド共有）
  • Web Storage （セッション／サイト データのクライアント側 保持）
  • HTML の構文 ¶
    • Writing HTML documents （ HTML の書法 — 要素タグとその省略, 属性, テキスト, その他）
    • Serializing HTML fragments （ HTML 素片の直列化法 ）
    • Parsing HTML documents （ HTML 文書の構文解析法）
    • Parsing HTML fragments （ HTML 素片の構文解析法）
    • Named character references （すべての有名文字参照 一覧）
  • XML syntax （ XML 構文による HTML （ “XHTML” ））
  • Rendering （ HTML における既定の UA スタイル, 呈示ヒント）
  • Obsolete features （廃用にされた要素, 属性, 他） （ Requirements for implementations （実装に課される要件）節は、未訳）
  • （未訳） IANA considerations （他サイト訳）
  • （未訳） Acknowledgments （謝辞）
• ストレージ ¶
  • Storage Standard （各種ストレージ特色機能を持続化する／ ストレージ空き容量の見積もりを取得する ための API ）
  • File API 仕様 （利用者から供されるファイルデータの読み取り ／ メモリ内のデータを参照する Blob URL ）
  • Web Storage （セッション／サイト データのクライアント側 保持）
  • Indexed Database API 3.0 （索引付きデータベース API — トランザクションに基づくクライアント側データ蓄積）
• UI イベント／UX ¶
  • UI Events （ 利用者インタフェース関連の基本的なイベント）（旧 DOM3 Events ）
  • UI Events KeyboardEvent key Values （キーボードイベントに可用なキー値の一覧）
  • Pointer Events — Level 2 （マウス, タッチ, ペン などの種々のポインタ装置によるイベントを統一的に扱う）
  • Touch Events — Level 2 （タッチイベント）
  • Input Events （テキスト入力イベント）
  • HTML — Drag and drop （ドラッグ＆ドロップ）
  • Intersection Observer （要素の “可視率” の変化（スクロール時など）を検出する）
  • Fullscreen API （要素を全画面化するための API ）
  • Notifications API （利用者に通知を表示するための API ）
  • CSS 関連, HTML イベント索引
• ネットワーク ¶
  • Fetch 標準 （リソース取得のための包括的かつ基盤的な処理モデル）
  • XMLHttpRequest （ HTTP リクエスト／応答の送受信）
  • RFC 6455 — The WebSocket Protocol （ Web のための双方向通信プロトコル）
  • WebSocket API 仕様 （同上, クライアント側 API ）
  • HTTP ¶
    • RFC 7230 — Message Syntax and Routing （ HTTP/1.1 の，メッセージの構文とルーティング）
    • RFC 7231 — Semantics and Content （意味論と内容）
    • RFC 7232 — Conditional Requests （条件付き要請）
    • RFC 7233 — Range Requests （範囲要請）
    • RFC 7234 — Caching （キャッシュ処理）
    • RFC 7235 — Authentication （認証の枠組み）
    • その他の 拡張仕様 （ RFC6265, RFC6585, RFC7538, RFC7615, RFC7694, RFC7725, RFC8246, RFC8288 ）
  • Reporting API （ Report-To HTTP ヘッダ — CSP 違反やネットワークエラーなどの報告先をサーバ側から設定する）
  • Network Error Logging （ NEL HTTP ヘッダ — ネットワークエラーの報告先をサーバ側から設定する）
  • HTML 関連： ナビと閲覧, メッセージ通信
• セキュリティ ¶
  • RFC 6454 — The Web Origin Concept （生成元（オリジン）の概念）
  • Content Security Policy Level 3 （ XSS 対策のためのフレームワーク — 略称 “CSP” ）

    Level 3 は，他の仕様との統合に適するように全面的に書き直された CSP 仕様。 旧版は： CSP Level 2 （勧告）

  • Mixed Content （ https （セキュア）ページから http （非セキュア）リソースを fetch するときの取り扱いと制御法）
  • Secure Contexts （セキュア文脈に制約される特色機能／非セキュア文脈との隔離／セキュア文脈かどうかの簡易な判別 API ）
  • Referrer Policy （リファラの制御法 — Referrer-Policy HTTP ヘッダ）
  • Subresource Integrity （ページが読み込む外部の下位リソースに対する改ざんリスクから保護する）
  • Upgrade Insecure Requests （ページ内のあらゆる非セキュア URL（ http:// ）を，透過的かつ互換性を保ちながらセキュア URL （ https:// ）に昇格させる）
  • Permissions （ “強力な特色機能” の利用についての許可を要請する／照会する）
  • Feature Policy （ “特色機能施策” — 個々の特色機能の利用を（埋め込んだ内容などに）選択的に許可する／阻止する）
  • MIME sniffing （ MIME 型の推定法）
• パフォーマンス／計時関連 ¶
  • Page Visibility （ページ可視性の判別）
  • High Resolution Time （高精度計時）
  • Performance Timeline （他の計時関連仕様の基盤）
  • User Timing （利用者による計時）
  • Navigation Timing （ナビゲーション（ページ遷移）の計時） （ Level 1 もこの仕様内）
  • Resource Timing （リソース取得の計時）
  • Resource Hints （リソースを先取り的に取得／具現化して， UX を改善する）
  • Preload （必要になるリソースを事前に読み込んで，処理能を改善する）
  • Cooperative Scheduling of Background Tasks （ requestIdleCallback() メソッド — バックグラウンドタスクを，時間に厳しい他のタスクを邪魔することなく実行するための API ）
  • Paint Timing （塗りの計時）
  • Beacon （ sendBeacon() メソッド — 文書の unload 時にサーバに向けて非同期にデータを送信させる）
• CSS／SVG — グラフィックス／変形／塗り ¶
  • Geometry Interfaces Module Level 1 （ 2 次元／3 次元の 点, 矩形, 行列などを表現する基本的インタフェース）
  • CSS Transforms Level 1 （ 2 次元の座標系変換による変形）
  • CSS Transforms Level 2 （ 3 次元の座標系変換による変形）
  • 画像／色／塗り ¶
    • CSS Color Module Level 4 （色と透明度を指定する種々の方法）
    • Compositing and Blending （色の合成と混色）
    • CSS Images Module Level 3 （画像内容やグラデーションの指定，置換内容の配置／サイズ制御など）
    • CSS Images Module Level 4 （他の要素の描画を複製する／円錐型グラデーション（未訳）／解像度の制御）
    • CSS Backgrounds and Borders Module Level 3 （背景画像／境界線／境界線画像の指定，境界線の丸め, 影の付与）
    • Filter Effects Module Level 1 （フィルタ効果）
    • CSS Masking Module Level 1 （マスク処理）
  • SVG／SVG2 ¶
    • SVG 1.1 仕様（第 2 版）
    • Changes 章 （ SVG 1.1 から SVG 2 までの変更点）
• CSS ¶
  • プロパティ一覧, 記述子一覧, CSS Snapshot 2018（現在の安定的 CSS） , 原文 CSS 関連仕様一覧
  • 基盤 ¶
    • CSS Cascading and Inheritance Level 4 （カスケードと継承の仕組み — 指定値, 算出値, 使用値, 実効値，および 初期値, 継承値）
    • CSS Values and Units Module Level 4 （ CSS プロパティの各種 値型と単位，プロパティの値定義の構文とその意味）
    • CSS Syntax Module Level 3 （ CSS の一般構文とその解析アルゴリズム）
    • CSS Custom Properties for Cascading Variables Module Level 1 （カスケード変数を定義するカスタムプロパティ）
    • CSS Style Attributes （文書言語が規定するスタイル属性に対する取り扱い）
  • セレクタ ¶
    • Selectors Level 4 （レベル 4 までの CSS セレクタ／疑似クラス）
    • CSS Pseudo-Elements Module Level 4 （疑似要素）
    • CSS Scoping （ shadow DOM 用のセレクタ）
    • CSS Non-element Selectors （非要素ノードを選択するセレクタ（非 CSS 用））
    • CSS Namespaces Module Level 3 （ CSS における名前空間の利用）
  • HTML 関連 ¶
    • Matching HTML elements using selectors （ HTML の UI 要素を対象にする動的 CSS 疑似クラス）
    • HTML Standard — Rendering （ HTML における既定の UA スタイル, 呈示ヒント）
    • Compatibility （ Web 互換性のために UA に要求される非標準の CSS ／ DOM API サポート）
  • メディア対応 ¶
    • CSS Conditional Rules Module Level 3 （条件付きで適用される CSS 規則）
    • Media Queries Level 4 （レベル 4 までのメディアクエリ）
    • Media Queries Level 5 （レベル 5 （ レベル 4 からの差分））
    • CSS Paged Media Module Level 3 （印刷のためのスタイル）
    • CSS Speech Module （読み上げ音声スタイル）
  • 視覚レイアウト（全般） ¶
    • Box Model （ CSS Level 2 ） （ボックスモデル — マージン, パディング, ボーダー）
    • CSS Display Module Level 3 （レイアウトモデルを定義する display プロパティの Level 3 拡張 ／ 種々のレイアウト関連の概念の定義）
    • CSS Intrinsic & Extrinsic Sizing Module Level 3 （ 内容に基づく “内在的” サイズ, と 文脈に基づく “外在的” サイズ ）
    • CSS Writing Modes Level 4 （縦書き／横書き，書字方向の指定法，それによる各種レイアウトへの影響）
    • CSS Logical Properties and Values Level 1 （書字方向に相対的な各種プロパティ, 値）
    • CSS Box Alignment Module Level 3 （ボックスたちを 互いに, あるいは親の中で整列する）
    • CSS Fragmentation Module Level 3 （フローの断片化 — 改ページ／改カラム／改 region）
    • CSS Shapes Module Level 1 （任意の図形を回り込むようにレイアウトさせる）
    • CSS Exclusions Module Level 1 （排他区画の指定 — 要素の外側のテキストが要素が占める区画を回り込むようにする）
  • 視覚レイアウト（各種レイアウトモデル） ¶
    • “通常フロー” （ CSS Level 2 ）
      • Visual formatting model （視覚整形モデル — 位置決め, ブロック, 行内, 浮動体, コンテナ, 整形文脈, 積層文脈）
      • Visual formatting model details （視覚整形モデルの詳細 — 横幅, 縦幅 他）
    • CSS Flexible Box Layout Module Level 1 （伸縮／整列 “自在” ボックス レイアウト）
    • CSS Multi-column Layout Module （段組レイアウト）
    • CSS Grid Layout Module Level 1 （格子レイアウト）
  • テキスト組版 ¶
    • CSS Writing Modes Level 4 （縦書き／横書き，書字方向の指定法）
    • CSS Fonts Module Level 3／ CSS Fonts Module Level 4 （フォント）
    • CSS Font Loading Module Level 3 （フォントを動的に読み込むための API ）
    • CSS Text Module Level 3 （空白の縮約法／行の折返し／改行規則とハイフン挿入／整列と両端揃え／アキ組／字下げ／文字大小変換）
    • CSS Inline Layout Module Level 3 （テキスト内容の，行に直交する方向の位置決め ／ 段落の先頭字の整形）
    • CSS Text Decoration Module Level 3 （テキスト装飾 — 装飾線, 圏点, 影）
    • CSS Ruby Layout Module Level 1 （ルビ）
  • アニメーション ¶
    • CSS Timing （タイミング関数）
    • CSS Transitions （遷移効果）
    • CSS Animations （アニメーション）
    • Web Animations, その API （ CSS, SVG のアニメーションを統合するモデルと API ）
  • 生成内容
    • CSS Counter Styles （定義済みのカウンタスタイル, 作者定義によるカウンタスタイル）
  • UX （ ユーザインタフェース／パフォーマンス最適化など） ¶
    • CSS Level 2 — Visual effects （視覚効果 — 過フロー, 切り抜き, 可視性）
    • CSS Overflow Module Level 3 （過フローの制御）
    • CSS User Interface Module Level 4 （ UI に関する種々のスタイル）
    • CSS Will Change Module Level 1 （動的パフォーマンス最適化のためのプロパティ）
    • CSS Containment Module （ページ内の一部分に対する効果が，外側に波及しないようにする）
    • CSS Scroll Snap Module Level 1 （スクロール位置を指定した区分ごとに自動的に揃える）
    • CSS Scroll Anchoring Module Level 1 （レイアウトが動的に変化しても，利用者が見ている内容は ずれないようにする仕組み）
  • CSS オブジェクトモデル（ CSSOM ）／ “css-houdini” ¶
    • CSS Object Model (CSSOM) （スタイルシート操作のための API ／ オブジェクト表現による CSS から 文字列表現による CSS への直列化）
    • CSSOM View Module （視覚的レイアウト情報（要素や選択範囲の 位置／サイズ，他）へのアクセス API, スクロール位置の取得や設定のための API，他）
    • CSS Typed OM Level 1 （“型を備える” CSS オブジェクトモデル）
    • CSS Properties and Values API Level 1 （新たなプロパティを定義して登録するための API ）
    • Worklets （ CSS, Audio などのカスタム具現化スクリプト用の worker 環境 ）
• JSON
  • RFC 6901 — JavaScript Object Notation (JSON) Pointer （ JSON データ内の特定の部位を参照するポインタ）
  • RFC 6902 — JavaScript Object Notation (JSON) Patch （ JSON リソースに部分的な変更を加える操作を記述するためのデータ形式）
• XML ¶
  • Namespaces in XML 1.0/1.1 （ XML 名前空間 ）
  • XML Base （第２版） （ 基底 URI ）
  • Associating Style Sheets with XML documents （ <?xml-stylesheet …?> 処理命令）
  • XPath 1.0 （ XPath 言語 ）
  • XSLT 1.0 （ XSL 変換 ）

各ページ共通の機能

本文ダブルクリック

ページの左右端をクリック

当該箇所の原文を表示。

ページ左下隅のボタン

• 目次のサイドメニュー化切替（アクセスキー A ）
• （用語やインタフェースメンバなどの）索引を表示（アクセスキー S ）
• 原文の全表示切替（アクセスキー Z ）
• 語彙の対訳切替（アクセスキー X ）

見出し／定義項目† のクリック

次が含まれたパネルが表示される：

1. その項目自身を指すリンク††
2. 原文仕様の中の，対応する同じ項目を指すリンク（ “原文” ）†††
3. ページ内の，その項目を指しているリンク一覧

パネル表示中は、左右矢印キーにより，これらのリンク先（“原文” を除く）を巡回できる。

† id が付与された項目 — 具体的には、 章／節の見出し, 定義用語, インタフェースのメンバ定義, 定義リストの見出し, 参照文献の見出し, CSS の各種プロパティやその値, 値型， 等々。 †† リンクテキストには、章／節 の見出しについては その原文，他の場合は その項目の id が示される。 ††† 和訳のみに id が付与されている項目については示されない。 また、自動処理の都合などから、原文と異なる id が付与されている項目もあるが、その場合でもリンクは元の id を指すようにしている（逆に，和訳ページが元の id でアクセスされた場合も同様）。

対訳切替など，一部機能は省略されているページもあります。

各ページ共通の表記規約

以下に述べる表記規約は原則であり，ページ間で多少異なることもあります。

語彙の対訳について

日本語と英語には（特に文の構造に）大きな開きがあるので、語彙以前に，原文を論理的に等価な言い回しに変形することも よくあります — 例えば，対偶をとるなど。 （挙げていくと際限ないが，実際には、英語のすべての定冠詞（の有無, あるいは all, every, each 等々）, あるいは語形変化など、およそすべて， “等価な” 言い回しに変形することになる。 双方の言語には，利用する語彙そのものに異なる視点が組み込まれているので、より適する言い回しも，必然的に異なることになる。 単語の省略法も異なるので、原文に無い語を補完したり，逆に原文の語を省略することも ときには必要になる。 ）

また、英語は動詞が中心的な意味を担う場合が多く、プログラミング言語で言い換えるなら，いくつかの callback 関数を入れ子にして記述するのに近い感がある（直訳的には、 “〜することを〜することを〜することを … 〜する” のように — 5 段くらい入れ子にされることも珍しくない — そのような入れ子の動詞は、主語や目的語, あるいはその両者が省略されていることも多い（事実上、英語の方が日本語より主語や目的語の省略は多いかもしれない））。 ついでに、英語の動詞（例： serialize ）は ある関数を実行すること, 動名詞 〜ing （例： serializing ）は 関数のある実行インスタンス, 動詞を語源とする名詞（例： serialization ）は 関数を実行した結果（あるいは関数の定義）に対応付られるような感もある。

マークアップや自動処理などの編集上の都合が，以下の原則より優先されている箇所も中にはあります。

仕様が規定するモデルの定義をより明確化する／簡潔にするため、和訳では，明示的に定義用語とされていない語にマークアップを施したり, 新たな用語を導入することもあります。 例えば、ある語 X が，単独の個としての意味と いくつかの集合としての意味を兼ねて定義されることもよくある — 英文では， “X”, “Xs” のように単数形と複数形で自明に／慣用的に区別し得ても、和文では， “X”, “X リスト” のように，明示的に分けて定義しないと不明瞭になることがある。

• 原文に含まれている情報を訳文の中に可能な限り正確に反映させるための一環として、語彙とその対訳は、なるべく，一対一の対応関係†（より厳密には単語単位ではなく，句や意味構造の単位による対応関係）が保たれるようにしていますが、仕様が扱う対象や技術的内容など，利用される文脈に依存するので（ときには仕様の編集者が好んで用いる表現にも）、特に分野が異なる仕様間では，必ずしも統一されてはいません。 （† 一般に，一対一の対訳だけでは不足とされるが、他所（同じ仕様の, あるいは関連する他の仕様）との 整合性をとる／関連性を断たないようにする必要もあるので，一対一をないがしろにするわけにもいかない）（ 一般的には、日本語／英語の単語をノードに見立てて，それぞれの言語の各単語の関係性を平面グラフに描いたとしたとき、互いに双対グラフのような関係にあると考えた方がよいであろう。）

  この種の重複は，同一仕様の中では（言い回しなども利用して）なるべく避けています （例えば： “get” ／ “fetch” ／ “obtain” ／ “retrive” ／ “aquire” ／ “achieve” ／ “gain” … → “取得する” ／ “取得をかける” ／ “得る” ／ “検索取得する” ／ “獲得する”, … 等々）。 多くの場合、同じ対訳が用いられても形式的には特に問題ない所でも、意味的／語源的／役割的に異なる含みが込められていたり，文脈を識別し易くする目的で 異なる語が利用されることも見受けられるので（もちろん，この種の厳密的な対応付けが必須になる場合も多いが、当初は気付かなかった訳出の不足点を見つけたり, 後から修正する際にも役立つので）。

  逆に，同じ語句に異なる表現を使い分けることは、比較的 多くなっています — （ “set” → “設定” ／ “集合” の様に原語自体が多義的に見える†ものに限られず） 例えば “match” → “合致”／“照合” や, “change” → “変更” ／ “変化” など （主題とされている対象から見て，その効果が能動的／受動的いずれになるかによっても，対訳が変わる／変わらざるを得ないことも）。 しかしながら，逆に使い分けを抑制している場合もあります （例えば， “align” の対訳には “整列する”, “〜寄せ”, “揃え” などがあり，馴染まれている表現も文脈によって異なり得るが、その様な場合でも，敢えて一つの表現に統一することがある。） （英語自体，同一の対象を様々な語彙で言い換える書き方が好まれる傾向もあり、編集者によっては，その頻度が高いこともある — その場合、ある程度 “正規化” して和訳しないと，何が “同じもの” を指しているのか不明瞭になり，読者を困惑させることになるであろう。） （† 多義的とは言い切れない面もある … 例えば、設定 → 一定の何かが設定されているものの集まり，のような意味論上の関連性は考えられる。 同様の例として、 “load” の対訳には，動詞に対する “読み込む” と名詞に対する “負荷” の二つが挙げられるが、英語話者にとっては，同じ概念に帰するのではないかと思われる。 ）

  仕様間の対訳の不統一も，その必要性が薄ければ避ける方針なので、一部の語の対訳には多少の冗長さ／不自然さ／馴染み難さを感じる所はあるかもしれません。 （例えば “feature” の対訳に利用されている “特色機能” は， “機能” とされても特に問題ない箇所もあるが、頻出する語でもなく, 単なる機能以上の含みもあるので、 “function”, “work”, “ability”, “capability” などの対訳との重複を避ける方を優先している。 ）

• 一部の用語には、定訳が見当たらないなどの理由で訳者による対訳があてがわれていたり（その種の対訳は後で変更されるかもしれない），カタカナ表記（外来語）に普及度が高くない漢字の対訳を用いています（要するに訳者の好き勝手にやっている）。 文脈が幅広い一般文章の中のカタカナ表記には：

  • 用語を判別し易くする（例えば DOM Range オブジェクトを意味する “range” を “範囲” と記した場合、一般的な意味の “範囲” と区別が付きにくく，都合が悪い）。 言い換えれば，形式論的な部分と意味論的な部分を区別し易くする、あるいは、 カタカナ表記は、英語の定冠詞の，一部の機能（ “周知のもの” を指すための “the” ）を担っているとも考えられる。
  • 原語がわかり易くなる — その結果，コード類との対応関係も読み取り易くなる。
  • ネット上その他の一般文書との用語の相違も生じ難い — その結果，ネット検索にかかり易くなる。
  • 同音異義語の問題を避ける（例えば “規定”, “既定”, “基底” — これらは他者と会話でやり取りする際には，問題になる）。
  • それ自身は意味を持たない記号のように扱い、余計な先入観を排除する／言外の意味や含みがある様な印象を与える（ “オリジン” は “オリジン” であって， “生成元” 等と訳される（解釈される）べきではない）。
  • 語形変化を反映し易い。 例えば動名詞 “〜ing” の場合、用語として動詞と対訳を異ならせるための決まった法則がない（ “〜付け”, “〜処理”, “〜法”, “〜時”, “〜用の”, “〜元”, … 等々を用いたりするが†、この種の語尾は内容を理解した上で選定する必要があり，仰々しくなったり, 文脈に応じて変える必要が生じたり, 相応しいものが見当たらない場合もある）。 用語として［ 単数形と区別すべき複数形, あるいは 集合としての複数形と区別すべき総称としての複数形, あるいは 現在形と区別すべき過去形, ］††などもしばしば現れ，同様のことが言える。 † 動詞に言い換えて訳されるときに，語形を変えずに（例えば、 “レンダリングする” の様に）記されることがよく見られるが、これは重言に近くなるので（ “render することをする”），和訳では語形も変えている（ “レンダーする” ）。 †† 和訳時に解り難くなる要因の一つとして、意識して与えない限り，英語の定冠詞や複数形などによる［ 語が［ 総称的／個別的（インスタンス）／集合的 ］のいずれを表すかを指示する情報 ］が失われることが挙げられる。 語尾変化についても同様で、例えば CSS 用語の “（〜の）包含ブロック（ containing block ）” などは，実際は “（〜を）包含しているブロック” と記された方が理解し易いと思われる（さすがに “コンテイニングブロック” などと記すのには，かなり抵抗がある）。

  などの利点が考えられますが、ここでは：

  • 文脈が限定されている。
  • 大抵の用語にはその定義を参照するリンクなど，何らかのマークアップが施され, 一般語と区別できる。 （ 特に最近の仕様は，あらゆる詳細を定義する傾向にあり、明示的に参照先が付与されていない（些細な）語彙でも，何らかの定義が仕様化されていたりするので、ほぼ全文がリンクで埋め尽くされる日も来るかもしれない（実際，和訳に利用している一部の記号には 仕様化されているものもあり、和訳では，リンクを省略して上述したアルゴリズム表記規約に代えている — “詳細過ぎ” で使い勝手が悪いので）。 ）
  • ほぼすべての語句が用語であると言っても過言ではない（仮に DOM の “文書”, “要素”, “属性” が全部 “ドキュメント”, “エレメント”, “アトリビュート” 等と記されたとすると，読みづらくなるであろう — その気になれば内容のほぼすべてが カナ／かな で占められてしまう仕様も中にはある — 日本語が介在し得る余地は、句読点, 代名詞, “てにをは”, 数量, すべて／ある／それぞれ などの、最小限にもなり得る。 その “てにをは” に該当する前置詞ですら，（他の語との組み合わせによる）用語としての扱いを要する場面は，しばしば現れる。 現在は用語でない単語でも，後に用語とされる場合もある。 ）。 “代入”, “同じ”, “〜である” などの基本的な語も見た目ほど自明と限らない — 突き詰めれば、翻訳など無意味な行為であり，さっさと日本語使うのやめるのが早道とも言える。 中学生あたりでネイティブ感覚で英語をマスターできなかった時点で，もう遅い。
  • 形式論と意味論の境目は、仕様ごとの文脈に依存する（ある基礎的な仕様の中では，形式論的な部分として強調される語彙も、それに立脚する別の仕様の中では，より概念的な名前で参照されることになるであろう — 例えば， “文字” は “キャラクタ” と記されるべきだろうか？ そう記した所で、その語 “キャラクタ” に， バイト単位, Unocode 符号位置, UTF-16 符号単位, 書記素クラスタ, 等々 のどれを指すのかについての情報が付与されるわけでもない — カタカナと漢字による区別だけでは、結局，足りなくなる ）。 元々の原文の記述自体が，形式論と意味論の重ね合わせになっている（カタカナ利用はそれを断ち切ってしまう面もある — 語がどちらを意図して記されているかも、自明でない）。
  • 用語は用語であって結局は外国語と同じ — “生成元” は “生成元” であって，一般概念としての「生成元」に解釈することが義務付けられるわけではない（例えば木構造の文脈の “親” は別に “二人” 居るわけではない）し、和語や漢語が言外の意味を備えては ならない わけでもない。 結局は，他の語との関係を通して理解される／するしかないものであろう（ゆえに、翻訳にあたっては，その関係を明確化することを重視する）。
  • 原文も併記しており、多くのページは対訳の切替機能（原語表示, 一部ではカタカナ表示も）を備えている（カタカナより原語表記で直接的, 視覚的に覚えた方がむしろ効率的で有利ではないのか？）。 （ しかしながら、前置詞／接続詞／基本的な動詞それ自体が独立の用語になることもあり（例えば，アニメーションの from, to の他にも then, done などが挙げられる）、これらの語がコードに現れると同時に意味論の記述の中の単語とも深く関連付けられている場合、その関連性を自然な形で和訳に反映させるのは困難になる（そのような単語をそのまま原語で（あるいはカタカナでも）記したなら，日本語にならなくなるので）。

  ことから、漢字表記による，概念（あるいは用途／役割）の把握し易さ／関連の一般語との概念的な関わりの維持／記述の簡潔さを多少優先させています（コード類との対応関係の判り易さについては，翻訳行為 自体と相反するので、ある程度 目をつぶらざるを得ないですが）。 例えば：

  • “ドキュメント” （ document — DOM として扱われるリソース, または それを表現するオブジェクト）は基礎的な語でもあるので → “文書”
  • “ブラウジングコンテキスト” （ browsing context ） は長いので → “閲覧文脈”
  • “コンテンツ” （ contents ）はメディア／著作物など特別な意味を有するわけでもなく，カタカナで記す意義が感じられないので → “内容” （ “内容” が “content(s)” 以外の意味で用いられる箇所は無いに等しい（これらを使い分けることに利点はあるのか？））
  • “コンテキスト” （ context — 与えられた情報を解釈する際の前提とされる情報）も同様に → “文脈” （ “文脈” を文章に関する語に限らせる必要もない／ con-text という語自体， “テキストと共に” を意味する）
  • “セレクタ” （ CSS selector ）は本文中の “選択（ select ）する” 等の記述との概念的な関わりを保つ／無為に語彙を増やさないため → 選択子
  • エンコーディング, エンコード, エンコーダ（ encoding, encode, encoder ） は概念の違いを解り易くするため → “符号化法”, “符号化”, “符号化器”

  （ その他、カタカナ利用の理由には，表現を婉曲にする（ “便所” → “トイレ” など）などもあるが、その種の表現が仕様の文脈で必要になる場面は，通常ない。 しかしながら、和語にすると無用に “生々しく” なることが多いのも，カタカナ語が増える理由にあると思われる。 ）

• 対訳では、頻度が高い／通りがよい／長過ぎるなどの理由で略語や原語そのままが利用されたり（例えば：

  • “ユーザエージェント（ user agent ）” → “UA”
  • “オペレーティングシステム” → “OS”
  • “クロスサイトリクエストフォージェリ” → “CSRF”
  • “インタフェース プロトタイプ オブジェクト” → “interface prototype object”,

  等々）、あるいは，

  • 原文のコード類との対応関係を読み取り易くする（例えば CSS 用語の “import” には，対応する CSS キーワード "import" がある）
  • 適当な対訳が見当たらない（訳語が確定するまで保留）
  • 他の語の対訳との衝突が避けられないが，ニュアンスが異なる（または共用を避けて文脈を識別し易くする）
  • 語義が広くなり過ぎる
  • “活用” による変異を抑制する（例えば “index” は、利用される文脈に応じて “索引”, “添字”, “付番”, “〜番目”, “指数” など，対訳も（訳として自然な表現にするために）様々に変わり得るが、意味論上の関連性を保つため，原語のままにされるなど）

  その他の理由で原語のままにされる場合もあります。 （どちらで表記しようが，専門的 難しさは変わらないなら、略語／原語で記しても同じことであろう。）

• 一部の用語には，語彙の統一や節約 の観点から（あまり一般的でない）動詞としても機能し得る名詞や熟語が利用されています。 代表的な例として、 （例外の） “投出” など。 体言としての “投出” と動詞としての “投げる” の２種類を語を使い分けるのは，なるべく避けたいので。 同様に、例えば “transition” の対訳に “遷移する” （動詞）／ “トランジション” （名詞） の２種類を語を使い分けるのも好ましいとは思えないので（加えて，動詞を “トランジションする” とするのもリズムが悪い）、この種の事例では “遷移効果” ／ “遷移する” の様な表記を優先させています。

ローカル保存

著作権と利用許諾

上に挙げたページは翻訳なので二次著作物であり，その翻訳作業に関わる部分の著作権は翻訳者（連絡先）に帰属することになりますが、翻訳者はその利用について、原著作物の著作権に起因する制約を除き，次の通りと定めます：

• このページ自身, および ページ一覧 に挙げられている各ページ, および 各ページに関連するリソース（スクリプト, 画像, 等々） — すなわち， https://github.com/triple-underscore/triple-underscore.github.io の一覧リストに挙げられているもの — は、 クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンス の下に提供されています。 （日本語訳の参照先）
• これらを再頒布する／共有する際の［ ライセンス対象物の作者その他クレジットの表示 ］には，［ ウェブ上のリソースとして公開された当該の著作物の URL, および そのリソースを取得した日付 ］の表示が要請されるものとします。