ウェブ関連仕様 日本語訳

日本語訳ページ一覧

• 基盤
  • Character Model for the World Wide Web 1.0: Fundamentals （ Web のための文字モデル）
  • Web IDL 仕様 （ Web プラットフォーム API 定義言語）
  • DOM 標準 （ “DOM4” — 文書オブジェクトモデル API ）
  • URL 標準 （ URL 構文を完全に予測可能かつ相互運用可能なものにする）
  • Encoding 標準 （種々の符号化方式による文字列の符号化／復号 処理）
  • Fetch 標準 （リソース取得のための包括的かつ基盤的な処理モデル）
  • Writing Promise-Using Specifications （ promise を利用する仕様の書き方（読み方））
  • Promises/A+ （種々の JS ライブラリが準拠する， Promise の仕様）
  • Streams 標準 （ストリーム処理のための統一的な構成部品）
  • TypedArray 仕様 （型付き（有型）配列）
  • JavaScript, aka. Web ECMAScript （互換性のための ECMAScript ブラウザ実装）
• SVG 1.1 仕様（第 2 版）
• WHATWG HTML 標準（ “HTML5” ）
  • Common infrastructure （ HTML 仕様全体から共通的に利用される定義／手続き）
  • Conformance requirements （適合性の要件, および HTML 仕様が依拠する外部仕様により定義される用語の一覧）
  • Semantics, structure, and APIs of HTML documents （ HTML 文書, 要素, すべての要素に共通する内容属性）
  • Scripting （ HTML におけるスクリプト／イベントループの処理モデル）
  • Web Workers （スレッド処理 ／ ページ間スレッド共有）
  • Web Storage （セッション／サイト データのクライアント側 保持）
  • WebSocket （ WebSocket プロトコルのための API ）
  • Rendering （ HTML における既定の UA スタイル, 呈示ヒント）
  • Matching HTML elements using selectors （ HTML の UI 要素を対象にする動的 CSS 疑似クラス）
  • Drag and drop （ドラッグ＆ドロップ）
• ストレージ
  • File API 仕様 （利用者から供されるファイルデータの読み取り ／ メモリ内のデータを参照する Blob URL ）
  • Web Storage （セッション／サイト データのクライアント側 保持）
  • Indexed Database API （第２版） （索引付きデータベース API — トランザクションに基づくクライアント側データ蓄積）
• UI イベント
  • UI Events （ 利用者インタフェース関連の基本的なイベント）（旧 DOM3 Events ）
  • Pointer Events — Level 2 （マウス, タッチ, ペン などの種々のポインタ装置によるイベントを統一的に扱う）
  • Touch Events — Level 2 （タッチイベント）
  • HTML — Drag and drop （ドラッグ＆ドロップ）
• ネットワーク／セキュリティ
  • Fetch 標準 （リソース取得のための包括的かつ基盤的な処理モデル）
  • XMLHttpRequest （ HTTP リクエスト／応答の送受信）
  • Content Security Policy Level 3 （ XSS 対策のためのフレームワーク — 略称 “CSP” ）

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

  • RFC 6265 — HTTP State Management Mechanism （“クッキー”）
  • RFC 6454 — The Web Origin Concept （生成元（オリジン）の概念）
  • RFC 6455 — The WebSocket Protocol （ Web のための双方向通信プロトコル）
  • WebSocket API 仕様 （同上, クライアント側 API ）
  • HTTP/1.1 （ RFC 7230 〜 7235 ）
    • RFC 7230 — Message Syntax and Routing （メッセージの構文とルーティング）
    • RFC 7231 — Semantics and Content （意味論と内容）
    • RFC 7232 — Conditional Requests （条件付き要請）
    • RFC 7233 — Range Requests （範囲要請）
    • RFC 7234 — Caching （キャッシュ処理）
    • RFC 7235 — Authentication （認証の枠組み）
• パフォーマンス／計時関連
  • Page Visibility, バージョン 2 （ページ可視性の判別）
  • High Resolution Time, バージョン 2 （高精度計時）
  • Performance Timeline, バージョン 2 （他の計時関連仕様の基盤）
  • User Timing バージョン 2 （利用者による計時）
  • Navigation Timing, バージョン 2 （ナビゲーション（ページ遷移）の計時）
  • Resource Timing （リソース取得の計時）
  • Frame Timing （描画フレームごとの計時）
  • Cooperative Scheduling of Background Tasks （ requestIdleCallback() メソッド — バックグラウンドタスクを，時間に厳しい他のタスクを邪魔することなく実行するための API ）
  • Beacon （ sendBeacon() メソッド — 文書の unload 時にサーバに向けて非同期にデータを送信させる）
  • Network Error Logging （ネットワークエラーが生じたときに，その詳細をサーバに報告する）
• CSS
  • プロパティ一覧, 記述子一覧, CSS Snapshot 2015（ 2015 年 現在の安定的 CSS） ,
  • 基盤
    • Selectors Level 4 （レベル 4 までの CSS セレクタ）
    • CSS Cascading and Inheritance Level 4 （カスケードと継承の仕組み — 指定値, 算出値, 使用値, 実効値，および 初期値, 継承値）
    • CSS Values and Units Module Level 3 （ CSS プロパティの各種 値型と単位，プロパティの値定義の構文とその意味）
    • CSS Syntax Module Level 3 （ CSS の一般構文とその解析アルゴリズム）
    • CSS Namespaces Module Level 3 （ CSS における名前空間の利用）
    • CSS Custom Properties for Cascading Variables Module Level 1 （カスケード変数を定義するカスタムプロパティ）
    • CSS Style Attributes （文書言語が規定するスタイル属性に対する取り扱い）
  • HTML 関連
    • HTML Standard — Rendering （ HTML における既定の UA スタイル, 呈示ヒント）
    • Matching HTML elements using selectors （ HTML の UI 要素を対象にする動的 CSS 疑似クラス）
  • メディア対応
    • CSS Conditional Rules Module Level 3 （条件付きで適用される CSS 規則）
    • Media Queries Level 4 （レベル 4 までのメディアクエリ）
    • CSS Paged Media Module Level 3 （印刷のためのスタイル）
    • CSS Speech Module （読み上げ音声スタイル）
  • 視覚レイアウト — 通常フロー （ CSS2 ）
    • CSS Level 2 — Box Model （ボックスモデル — マージン, パディング, ボーダー）
    • CSS Level 2 — Visual formatting model （視覚整形モデル — 位置決め, ブロック, 行内, 浮動体, コンテナ, 整形文脈, 積層文脈）
    • CSS Level 2 — Visual formatting model details （視覚整形モデルの詳細 — 横幅, 縦幅 他）
    • CSS Level 2 — Visual effects （視覚効果 — overflow, 切り抜き, 可視性）
  • 視覚レイアウト（一般）
    • CSS Display Module Level 3 （ display プロパティの Level 3 拡張，種々のレイアウト関連の概念の定義）
    • CSS Intrinsic & Extrinsic Sizing Module Level 3 （ 内容に基づく “内在的” サイズ, と 文脈に基づく “外在的” サイズ ）
    • CSS Writing Modes Level 3 （縦書き／横書き，書字方向の指定法，それによる各種レイアウトへの影響や “上下左右”, “幅／高さ” の解釈）
    • CSS Logical Properties Level 1 （書字方向に相対的な各種プロパティ, 値）
    • CSS Box Alignment Module Level 3 （ボックスたちを 互いに, あるいは親の中で整列する）
    • CSS Fragmentation Module Level 3 （フローの断片化 — 改ページ／改カラム／改 region）
  • 視覚レイアウト（各種レイアウトモデル）
    • CSS Flexible Box Layout Module Level 1 （伸縮／整列 自在ボックス レイアウト）
    • CSS Multi-column Layout Module （段組レイアウト）
    • CSS Grid Layout Module Level 1 （格子レイアウト）
    • CSS Exclisions Module Level 1 （排他区画の指定 — 要素の外側のテキストが要素が占める区画を回り込むようにする）
    • CSS Shapes Module Level 1 （任意の図形を回り込むようにレイアウトさせる）
  • テキスト組版
    • CSS Writing Modes Level 3 （縦書き／横書き，書字方向の指定法）
    • CSS Fonts Module Level 3 （フォント）
    • 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 Color Module Level 4 （色を指定する種々の方法，色を操作する API ）
    • Compositing and Blending （色の合成と混色）
    • CSS Image Values and Replaced Content Module Level 3 （画像内容の指定とグラデーション他の Level 3 拡張，置換内容の配置／サイズ制御など）
    • CSS Backgrounds and Borders Module Level 3 （背景画像／境界線／境界線画像の指定，境界線の丸め, 影の付与）
  • アニメーション
    • CSS Transitions （遷移効果）
    • CSS Animations （アニメーション）
  • 生成内容
    • CSS Counter Styles （定義済みのカウンタスタイル, 作者定義によるカウンタスタイル）
  • CSS Transforms （座標系変換による変形）
  • パフォーマンス最適化
    • CSS Will Change Module Level 1 （動的パフォーマンス最適化のためのプロパティ）
    • CSS Containment Module （ページ内の一部分に対する効果が，外側に波及しないようにする）
  • ユーザインタフェース
    • CSS User Interface Module Level 3 （ UI に関する種々のスタイル）
    • CSS Scroll Snap Points Module Level 1 （スクロール位置を指定した区分ごとに自動的に揃える）
  • CSS オブジェクトモデル（ CSSOM ）
    • CSS Object Model (CSSOM) （スタイルシート操作のための API ／ オブジェクト表現による CSS から 文字列表現による CSS への直列化）
    • CSSOM View Module （視覚的レイアウト情報（要素や選択範囲の 位置／サイズ，他）へのアクセス API, スクロール位置の取得や設定のための API，他）
• 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” の場合、用語として動詞と対訳を異ならせるための決まった法則がない（ “〜付け”, “〜処理” “〜法”, … 等々を用いたりするが、この種の語尾は内容を理解した上で選定する必要があり，仰々しくなったり, 文脈に応じて変える必要が生じたり, 相応しいものが見当たらない場合もある）。 用語として［ 単数形と区別すべき複数形, あるいは 集合としての複数形と区別すべき総称としての複数形, あるいは 現在形と区別すべき過去形, ］†などもしばしば現れ，同様のことが言える。 † 和訳時に解り難くなる要因の一つとして、意識して与えない限り，英語の定冠詞や複数形などによる［ 語が［ 総称的／個別的（インスタンス）／集合的 ］のいずれを表すかを指示する情報 ］が失われることが挙げられる。 語尾変化についても同様で、例えば CSS 用語の “（〜の）包含ブロック（ containing block ）” などは，実際は “（〜を）包含しているブロック” と記された方が理解し易いと思われる（さすがに “コンテイニングブロック” などと記すのには，かなり抵抗がある）。

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

  • 文脈が限定されている。
  • 大抵の用語にはその定義を参照するリンクなど，何らかのマークアップが施され, 一般語と区別できる。
  • ほぼすべての語句が用語であると言っても過言ではない（仮に DOM の “文書”, “要素”, “属性” が全部 “ドキュメント”, “エレメント”, “アトリビュート” 等と記されたとすると，読みづらくなるであろう — その気になれば内容のほぼすべてが カナ／かな で占められてしまう仕様も中にはある — 日本語が介在し得る余地は、句読点, 代名詞, “てにをは”, 数量, すべて／ある／それぞれ などの、最小限にもなり得る。 その “てにをは” に該当する前置詞ですら，（他の語との組み合わせによる）用語としての扱いを要する場面は，しばしば現れる。 現在は用語でない単語でも，後に用語とされる場合もある。 ）。 “代入”, “同じ”, “〜である” などの基本的な語も見た目ほど自明と限らない — 突き詰めれば、翻訳など無意味な行為であり，さっさと日本語使うのやめるのが早道とも言える。 中学生あたりでネイティブ感覚で英語をマスターできなかった時点で，もう遅い。
  • 形式論と意味論の境目は、仕様ごとの文脈に依存する（ある基礎的な仕様の中では，形式論的な部分として強調される語彙も、それに立脚する別の仕様の中では，より概念的な名前で参照されることになるであろう — 例えば， “文字” は “キャラクタ” と記されるべきだろうか？ ）。 元々の原文の記述自体が，形式論と意味論の重ね合わせになっている（カタカナ利用はそれを壊す面もある — 語がどちらを意図して記されているかも、自明でない）。
  • 用語は用語であって結局は外国語と同じ — “生成元” は “生成元” であって，一般概念としての「生成元」に解釈することが義務付けられるわけではない（例えば木構造の文脈の “親” は別に “二人” 居るわけではない）し、和語や漢語が言外の意味を備えては ならない わけでもない。 結局は，他の語との関係を通して理解される／するしかないものであろう（ゆえに、翻訳にあたっては，その関係を明確化することを重視する）。
  • 原文も併記しており、多くのページは対訳の切替機能（原語表示, 一部ではカタカナ表示も）を備えている（カタカナより原語表記で直接的, 視覚的に覚えた方がむしろ効率的で有利ではないのか？）。 （ しかしながら、前置詞／接続詞／基本的な動詞それ自体が独立の用語になることもあり（例えば，アニメーションの 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” の対訳に “遷移する” （動詞）／ “トランジション” （名詞） の２種類を語を使い分けるのも好ましいとは思えないので（加えて，動詞を “トランジションする” とするのもリズムが悪い）、この種の事例では “遷移効果” ／ “遷移する” の様な表記を優先させています。

ローカル保存

著作権と利用許諾

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

このページ自身, およびこのページの ページ一覧 に挙げられている各ページは クリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。

加えて、これらを再頒布する際には、ライセンスの規定上，一意的に特定される著作権者の表示が必要になりますが、その際の著作権者の氏名の表示は義務ではなく，代わりに［ ウェブ上のリソースとして公開された当該の著作物の URL, および そのリソースを取得した日付 ］を付記することが要求されるものとします。

尚、上の ローカル保存 に挙げた，スクリプト, スタイルシート, その他のリソース†についても、（日本語訳ページの一部をなすものとして）同様の扱いとします。 （†画像などのリソースも，訳者により日本語化されているものがある）