このページは、 Web プラットフォーム関連の いくつかの仕様の日本語訳の一覧と， それらの日本語訳に共通な事項についての説明です。
これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、 日本語訳は公式なものではありません。 （誤訳が無いことは保証されません。 ［ 当の仕様の策定者たちが想定している／当の仕様に期待されている ］意味論を完全かつ正確に反映することは保証されません。 翻訳なので、 語彙レベルで原文と正確に一致する意味を表すことは決してありません。 日本語は自然言語なので、 誰がいつどこで読んでも同じ解釈になることは保証されません。 ）（ 実際に誤訳が見つかることも時折あります。 それらについては見つかり次第修正され， 加えて用語の対訳や言い回しなども時折修正されるので、 これらの翻訳が「完成」する日は永遠に来ません。 逆に原文仕様が誤っていることもあり、 明白な誤りと見受けられるものなど，日本語訳にて修正している箇所もあります。）
一部の仕様は日々改訂され続けているので （特に， WHATWG による Living Standard （ “生きた標準” ）／ W3C による Editor's Draft （ “編集者草案” ））、 日本語訳は最新版と一致していないことがあります。 また、原文の更新に伴う，訳の更新の際に取り込み漏れがあるかもしれません†。 その完全性は保証されませんが、 ツールを利用して不定期に検証されてはいます（多数の更新が積み重なったときなど）。 （† RFC 文書, W3C 勧告については、 原文の更新は無いので，和訳に埋め込みの原文との差分は検査済み。）
ほとんどのページは、 タイトルを除く内容すべてがスクリプト（ JavaScript ）により生成されているので、 スクリプトの有効化／サポート（ ES 6 （ ECMAScript 2015 ）以上）は必須です（この背景色のものだけそうでない）。 また， CSS ／ DOM ／ HTML の対応が古いブラウザでは、 表示が崩れたり，一部の機能が働かないかもしれません （古過ぎるブラウザ（すべての IE を含む）では表示すらされないでしょう — 他のブラウザをご利用ください） 。
ほぼすべてのページは、
仕様のメタ情報を，タイトルの下に 次のようなクリックで開閉できる UI （ details 要素）で呈示しています：
ここには、 当の日本語訳が元にしている原文についてや, 定型的な事項など，翻訳に関するメタ情報が記される。
ここには、 原文の冒頭に記されているメタ情報が，ほぼそのまま記される。 原文やその更新履歴, メーリングリスト, テスト一式, 実装報告, その他を指す URL など。 便宜のため、［ 原文に記されていない／他所に記されている ］メタ情報を追加することもある。
ここには、 原文の著作権情報が記される （が、仕様によっては，他所に記されることもある）。
ここには、 仕様内に記された課題（ issue ）, 定義されている IDL やプロパティ, 等々 を巡回するための UI が示される （多くの原文には，それらに対応する索引節があるが、 和訳では省略して このような UI に代えている）。
Github リポジトリ から全ファイルを一括ダウンロードできます（冒頭にある "Clone or download" から "Download Zip" を選ぶ）。
innerHTML, outerHTML, insertAdjacentHTML, DOM の直列化などの API
（原文日付： — 個々のページに示される これより過去の原文日付は、 概ね，この日付まで更新が無いことを表す。 ）
Window, WindowProxy オブジェクト
Location オブジェクト
Window, WindowProxy, Location オブジェクト関連
document.open() ／ document.write() など）
Navigator オブジェクト
— 未知な［
スキーム／内容型
］用のカスタムハンドラ, プラグインなど
メッセージ通信（ § Communication ） ¶
Pointer Events — Level 2： マウス, タッチ, ペン などの様々なポインタ装置によるイベントを統一的に扱う
Pointer Events — Level 3： より高分解能なポインタの状態変化や動き予測のサポート／ touch-action に対する拡張
中核仕様：
草案／試験的：
DOMHighResTimeStamp ）,
計時の基準
requestIdleCallback()：
時間を要するタスクを，時間に厳しい他のタスクを阻まずに実行する
sendBeacon() メソッド
— 文書の unload 時にサーバに向けて非同期にデータを送信する
SVG Native： ネイティブアプリ用の SVG プロファイル
<?xml-stylesheet …?> ）
メンバ定義／
CSS の各種プロパティやその値, 値型／
定義リストの見出し／
参照文献の見出し,
等々）。
次が含まれたパネルが表示される：
リンクテキストには、 章／節 の見出しについては その原文，他の場合は その項目の id が示される。
このリンクは、 和訳に限り id が付与されている項目に対しては示されない。 また、自動処理の都合などから、 原文と異なる id が付与されている項目もあるが、 その場合でもリンクは元の id を指すようにしている （逆に，和訳ページが元の id でアクセスされた場合も同様）。
実装状況や用例など、 Web 開発者向け情報。 該当するページが MDN サイトに実際にあっても， 和訳には まだ付与していないものもある（随時更新）。 また，対応する項目が複数ある場合でも、 （現時点では，代表的な） 1 個しか示されない。
“原文” ／ “MDN” を指すリンクは、 新たなタブ（またはウィンドウ）内に開かれ， それ以降も同じタブが再利用される （再利用させたくない場合、（文脈メニューなどを介して）明示的に指示する必要がある）。
対訳切替など，一部機能は省略されているページもあります。
以下に述べる表記規約は原則であり，ページ間で多少異なることもあります。
リンクは、次の３種の下線スタイルで呈示される：
英文仕様を指すリンクのうち一部では、［ マウスを重ねたとき／フォーカスしたとき ］に，リンク先文書の【日本語訳】へのリンクも追加で表示されます （日本語訳はバージョンが異なっていたり，部分訳の場合もあります） 。
その他のスタイルは、 原文のそれを残しているものもあれば， まったく違えているものあります。 例えば、 マージンや行間を日本語に適したスタイルに改めたり， 各 仕様で一貫するよう別のスタイルに置換するなど。
基本的には，原文に即する様にしてありますが、 次に挙げる理由から，使用タグやマークアップ構造を改めている箇所もあります：
日本語と英語の資質／約束事の違いに由来するもの — 例えば：
<var> タグが利用される）
は多用される。
そのまま訳すと文脈から自明でなくなる指示代名詞に対しても、
同様に多用される。
これらが翻訳結果の構成に大きく反映され、 見かけ上，原文と乖離する場合もときどきあります。
曖昧さや多義性を抑制する／視認性を改善する目的で、 句読点, 記号, 括弧類, その他の約物は積極的に利用されています （ 2 種類の句読点の混在など，日本語の一般的慣習を意図的に破っている用法もあります） 。 これらは、 仕様が対象にしている分野に関する知識や意味論に通じていない状態でも， 文脈から推定する労力を軽減し, 内容を正確に読み取り易くするためのものであり†、 必ずしも，［ 文法的な厳密さ（互いに無矛盾かつ, 解釈が常に機械的に一意に定まる，等）を備えている／ 適用可能な所には常に利用されている／ 全ページで完全に統一されている ］わけではありません：
（† また，訳者の理解度／翻訳意図をより鮮明に表すものでもあるので、 解釈／翻訳に誤りがあれば，それをより鮮明に示すことになる — 例えば，角括弧の用法： 英語の句 “strong X or Y” の解釈は、 文脈に依存して， “［ 強い X ］または［ Y ］” が意図されている場合もあれば， “強い［ X または Y ］” が意図されている場合もある。）
| 記号 | 説明／用法（原則） |
|---|---|
| 隅付き括弧 【, 】 | 訳者による【注釈／原文の補完】。 |
| 全角 丸括弧 （, ） | 後述の全角ダッシュとは対照的に、 主として，補助的な説明や例を挿入するために利用される （例えば、この括弧内に記した句のように）。 |
| 半角 丸括弧 (, ) | 主として，地の文の中で、 アルゴリズムの入力引数, あるいは数式を括るときに利用される。 （全角と見た目の区別が付きにくいが、文脈から容易に判別できるであろう。） |
| 全角 角括弧 ［, ］ | 修飾や条件などの対象範囲を明確化するための括り。 例えば、 ［［列挙された多数の語句］や長い語句］を文の中で一体として扱うとき， あるいは 読点の結合順位（後述）だけでは不足する場合など （例えばこの文では、 内側の ［, ］により “列挙された” が “長い語句” にかからないようにした上で， “一体として扱われる” 対象を明確化するために外側の ［, ］で括っている）。 特に必要がない所でも，同じパターンが繰り返されるときは、 パターンを強調するために利用されることがある。 また、長文の構造を読み取り易くする際にも利用される。 （これは、［ 話し言葉のように一息に話すことにより，ひとまとまりを表現するような柔軟性 ］を，多少なりとも書き言葉に付与するためのものでもある。 また、 書き言葉であるからして，発音できない各種記号を使わない手はないであろう — 語句の順序を 論理的な流れを追い易いものに保ちつつ，曖昧さを排除するためにも。 厳密さを追求するなら、 記号に頼らず，あらゆる関係構造をマークアップに落とし込んだ上で， CSS で呈示に反映させるのが理想であろうが。） |
| 全角コロン "：" | コロンの前の語句に，後続の文やブロックでその説明や定義を与える（特に，説明が長くなる場合）。 |
| 句点 "。" | 句点は "。" に統一。 |
|
全角読点 "、", 全角カンマ "，", 半角カンマ "," | 結合度の低い順に，左の３種類が読点として利用される。 結合度が全角読点の一種類で済む場合でも、 連続性が強い所では，カンマが用いられる。 また，半角カンマ（＋半角スペース）は、 文脈の中で等格な［ 語句／キーワード ］を列挙する際に特に用いられる。 （これらは，実質的に “［, ］” の略記と見なせることが多い。） |
| 全角ダッシュ " — " | この文のように，長めの語句を挿入する所 — 丸括弧が補助的な説明を挿入するのとは対照的に，規範的な語句を挿入するときなど — では、 2 個のダッシュで括られる。 この文のように，二つの文の関連性を明示する所では、 1 個のダッシュで繋げられる — 最初の文を句点で区切る代わりに。 （全角ダッシュ文字には U+2015 ( HORIZONTAL BAR ) ではなく, U+2014 ( EM DASH ) が用いられる。） |
| 全角スラッシュ "／" |
|
| 半角スペース | “小さな” 区切り：
|
|
二重引用符： （曲線型） “…” （半角） "…" | “曲線型” の方は、 通常の引用符（説明のための，比喩的／概念的な記述など）。 “半角” の方は、 仕様が規定するリテラルや記号類, 例示コード類の括りなど，意味よりも文字列そのものの同一性／忠実さが重視される所で利用される。 |
これらの記号を多用する理由は、 （前提として多義的に解釈されては困る）仕様の記述には，次に挙げるような資質があるため、 文脈から意味構造を一義的に決定するのが難しくなる傾向があることによる （例えば 「黒い目のきれいな女の子」 ）：
どの和訳にも，次に挙げる対訳が利用されています：
| 原語 | 対訳 | 要件レベル |
|---|---|---|
| MUST | 〜するものとする（ UA 要件 ） ／ 〜しなければならない | (a) |
| MUST NOT | 〜しないものとする（ UA 要件 ） ／ 〜してはならない | (a) |
| SHALL ／ SHALL NOT | MUST と同じ (*1) | (a) |
| REQUIRED | 要求される (*2) | (a) |
| SHOULD | 〜するべきである (*3) | (b) |
| SHOULD NOT | 〜するべきでない／ 〜しないべきである | (b) |
| RECOMMENDED | 推奨される | (b) |
| MAY | 〜してもよい (*4) | (c) |
| OPTIONAL | 任意選択 ／ “（省略可能／省略時は〜）(*5)” | (c) |
原則として、 上に挙げた以外の対訳は利用されていない筈です(*6)。 逆に、 他の句に上に挙げた対訳を利用することも避けています。 ただし，小文字の “must” 等は、 これらの語に対する大文字表記（またはマークアップ）が［ 省略されている仕様 ／ 省略されていない仕様で RFC 2119 の意味の下で用いられていると考えて差し支えない所 ］では、 マークアップを施さないまま，同じ対訳にしています。
多くの仕様では，以下に挙げるような慣用句が用いられています（括弧内は原文の表現）：
この句には、 一般に，次が含意される：
Foo として指示される場合、
O は “Foo オブジェクト” と称されることが多い
— この場合、
C は Foo インタフェースを実装するオブジェクトの集合を表すことになる。）
より形式的に述べるなら、 次のように規定されると解釈すればよいであろう：
C に属する任意の個体 O に対し，次の両者を満たすような個体 V がただ一つ存在する：
そのような V を指すときは、 “ O に結び付けられている P ”, あるいは単に “ O の P ” とも記される。
仕様には明文化されないことが多いが、 この結び付けは “専属的” な関係を含意することもある — すなわち， P に属する所与の個体 V に対し，関係 < C, P > を満たす C に属する個体 O は、 あっても 1 つに限られる。 一方で，該当しない場合もあり、 この区別は文脈から判断する必要がある。
foo() メソッド手続きは…”
（以下, 手続きの内容が後続する）
foo 手続きfoo に対する
“foo 手続き”
のような句は、
foo のふるまいを定義している手続きを指す。
foo が IDL 属性の場合、
手続きには取得子, 設定子の両方があり得るので，［
“foo 取得子手続き” ／
“foo 設定子手続き”
］のように記される。
ここでの arg は、 当のメソッドに宣言された引数であって，次をすべて満たすことが前提にある：
optional が付与されている
）
そのような引数に明示的に JavaScript undefined 値を渡してメソッドを呼び出した場合も、
missing に解釈されることになる。
（可変個引数（宣言に "..." が付与されたもの）に渡された undefined は、
必須の引数と同様に解釈される。）
（†省略可能な引数のうち， "= 既定値" が宣言されているものは、
その引数を省略した場合，既定値として 既定値 を渡したものと見なされる。）
仕様の中のアルゴリズムは、 有順序リストの入れ子階層によるマークアップにより， 一般的なプログラミング言語と同様の実行順序／制御構造が表現されています。
多くの仕様の和訳では、 アルゴリズムの中の定型的な記述を簡明に, かつ一貫させるため、 いくつかの記号を導入しています （個別の仕様ごとに，追加の記号が導入されることもあります）：
| 表記 | 意味 |
|---|---|
| Assert：条件 | いわゆる表明。 条件 で表現される暗黙的な不変則を明示的に示して， アルゴリズムの明確化を図るものであり、 アルゴリズムの意味論に要件を追加するものではない。 アルゴリズムの入力が満たしているはずの条件が記されることが多い。 |
| これ° |
IDL this 値 の略記。 論の対象のインタフェース（インタフェース mixin も含む）のメンバ （メソッド／属性取得子／属性設定子）が呼び出されているオブジェクト自身 — その種のメンバを定義しているインタフェースを実装している，ある特定のインスタンス — を指す（ JavaScript の “this” に ほぼ対応するが，定義は異なる）。 ほとんどの場合、当のメンバのふるまいを定義するアルゴリズムの中で利用される。 構築子手続きの中でも利用され、 当のインタフェースを実装する新たなインスタンスを指す。 この用語は頻出し，原文では単に “this” と記されることが多いが、 日本語的にすわりが悪いので （および JavaScript の this と混同されないよう）， 和訳では これ° と表記される。 |
| アルゴリズム名( 引数… ) | アルゴリズム名 が指示する手続きを 引数 （ 0 個以上）を渡して適用することの略記。 |
O 上の foo 手続き( 引数… )
|
IDL メンバ foo を実装しているオブジェクト O 上で，
foo 用に定義された手続きを
— 所与の 引数 （ 0 個以上）を渡して —
適用することの略記。
その手続き内の これ° は、
O を指すことになる。
|
| ε | 存在しないことを表現する特別な定数 （詳細は上述に）。 |
| ∧, ∨, ¬ |
論理演算用。 2 つの条件文に挟まれた ∧ は論理積（ “かつ” ）, ∨ は論理和（ “または” ）を表す。 条件文の先頭に置かれた ¬ はその否定（ “でない” ） を表す。 条件の順序は有意になることもある： ∧ の場合、 先に現れる条件が満たされない限り （ ∨ の場合は、その否定が満たされない限り）， 後に現れる条件が意味を成さないこともあるので。 |
|
A ＝ B, A ≠ B | ＝ は A と B が同じであることを表す（原文 “A is B” †）。 ≠ は ＝ の否定を表す。 仕様には明文化されていないことも多いが，同じであることの定義は、 比較対象が属する型に依存する — 通例的には、比較対象が［ オブジェクトの場合は 同一のインスタンスであるとき ／ primitive 値の場合は 値が等しいとき ］同じとされる。 （複合的な型の各成分の同等性を述べるときは、 一般に，専用の用語（例：同一生成元）や下に述べる注釈記号を利用して述べられるか，あるいは各成分を列挙して ( A1, A2, … ) ＝ ( B1, B2, … ) のように記される。） （† “A is a B” は、 通例 “A は B である” と訳される。） |
| A :← B | 新たな変数 A を導入した上で，その値を与えられた値 B （ B が変数などの値を持つ何かとして記されていれば、その値） に初期化することを表す（原文では “ Let A be B ” と記される）。 |
| A ← B |
既存の変数 A （または、プロパティや属性などの，値を持つ何か）への 値 B の設定（代入）を表す（原文では “ Set A to B ” と記される）。 論理的には、この表記が現れる前後において，次のように変化することを意味する：
（ :← や ← のような記法を用いる理由の一つは、 設定（もしくは定義）の日本語表現には “A を B とする”, “A を B に設定する”, “A が B になる”, “A を B にする”, “A は B とする”, …等々，多種多様な言い回しがあり、 文脈, あるいは A, B の役割や定義に依存して，どちらが設定される側になるかの解釈も変わり得るため，誤解の余地も生じ易い／文脈を汲み取る労力を要するので。 もちろん，何らかの表現を一貫して用いることは考えられるが、 訳者自身もしばしば，どの表現に統一されているのか忘れることがあるので。 要するに翻訳の手間を省くことも目的の一つにある。） IDL 属性 A に対するこの表記（あるいは初期化）は、 実際には， A に対応する “内部的な下層データ” を設定することを意味する （ IDL 属性自身は、アクセス用の演算子に過ぎない）。 この下層データは、 仕様には明示的には定義されないことが多い — その場合、 A 属性を定義しているインターフェースを実装する各オブジェクトは、同じ名前の［ 下層データを保持するための “内部スロット” ］を持つものと暗黙的に定義される。 |
|
A += n, A −= n | 変数 A に対する増減操作を表す。 += は加算, −= は減算を表し， n はその量を与える。 |
| +, −, ×, ÷ | （数式の文脈の下で）加減乗除算を表す。 単独の数値／変数に接頭された +, − は正負符号を表す。 （負符号 "−" は Unicode MINUS SIGN 。 除算は 原文では通例 "/" で記されるが、 他の区切り記号にも多用されるので，和訳ではなるべく "÷" を利用している。） |
| >, ≥, <, ≤ | （真偽条件の文脈の下で）数値の比較を表す。 |
| A 〜 B | 値の範囲を表す — A, B も含まれる。 ただし，A > B の場合の範囲は空集合になる （そうなる事例は滅多にないが）。 |
| { … } | 括弧内に挙げられた対象の集合を表す。 |
|
e ∈ S, e ∉ S | e の集合 S への所属（ ∈ ）を表す。 ∉ はその否定を表す。 例えば e ∈ { a, b, c, … } は、 e が右辺に列挙されたいずれかの項と同じ（ ＝ ）であることを表す。 |
| A ＝注釈記号 B | 注釈記号 が付いた比較は、 その記号の定義に基づいて解釈される （例えば “＝大小無視” は、 文字大小無視に基づく文字列の比較を表すなど）。 記号の意味は、 個々の仕様の中で定義される。 ＝ の代わりに ≠, ∈ なども利用される — その論理は 注釈記号 に定義される同値関係に基づく。 |
| IF 条件 ：ブロック | 条件 が満たされるときに限り，ブロックの内容を実行することを表す。 |
| ELSE [ IF 条件] ：ブロック | 直前に現れている, 同じ階層レベルの［ IF および それに後続する ELSE IF ］に与えられた どの条件も，それが評価された時点で満たされなかったときに限り （すなわち，それらのどの ブロック も実行されなかったときに限り）、 加えて， IF 条件 が与えられている場合は その条件も満たされるときに限り、 ブロックの内容を実行することを表す。 したがって， ELSE 単独で現れている場合、 当の条件節の終端を表すことになる。 |
〜 に応じて：
| いわゆる switch 文。 〜 に記された対象が後続の どの 条件1, 条件2, … を満たすかに応じて、 対応する ブロック のみを実行する（あるいは，その記述に従う）ことを表す。 各 条件 は、 多くの場合，対象がとる［ 値／値の範囲 ］として記される。 その場合、 対象の値が［ 示された値と同じ／ 示された範囲に入る ］という条件として解釈することになる。 各 条件 による場合分けは，通例 排他的になるが、 そうでなければ何らかの処理規則 （例えば， “最初に該当する段を実行する” など） が付記されることになる。 |
| WHILE 条件 ：ブロック | 条件 が満たされる間，ブロック の内容を繰り返し実行することを表す。 条件 は、 各 反復の最初に評価される。 条件 に “無条件” と記されている場合、 無限に繰り返すことを表す （ ブロック の中の BREAK や RETURN などにより繰り返しを終える）。 |
| … 各 ( … 対象 ) に対し ：ブロック | “…” に記された［ 対象範囲に属する, あるいは条件を満たす ］ような 対象 それぞれについて — その列挙順序が明示的に指定されていれば その順序に従って — ブロック の内容を実行することを表す（ “for each” ）。 列挙順序が指定されていない場合，一般に、 対象範囲が リストなど元々順序を備える（または その一部を成す）ならば，その順序に従う。 処理結果が列挙順序に依存しないものについては，順序が指示されないこともあるが、 依存する場合は，実装依存になる可能性がある。 |
| CONTINUE | 繰り返しループ（ WHILE … ／ “各 ( … )” ）において、 現在の反復を中断して，次の反復へ移行することを表す。 |
| BREAK | 繰り返しループから抜けて，ループブロックの次の段へ移行することを表す。 |
| BREAK ラベル | ［ BREAK が記された段の上位レベルにある， ラベル が付与された段 ］全体を中止することを表す （ BREAK 以降を走らすことなく， ラベル が付与された段の次の段へジャンプする）。 ラベル が付与された段を “一度だけ反復するループ” と見なせば， BREAK と同じになる （他のループが入れ子にされていない限り）。 |
| GOTO ラベル | ラベル が付与された段へジャンプすることを表す。 |
| THROW 例外名 |
名前 例外名 の 例外オブジェクト† を 投出した上で、 特に並列的に実行を継続するよう指示されていない限り，現在の手続きも終了することを意味する。 例外は、例外を投出したアルゴリズムを呼び出したアルゴリズムにも伝播する。 すなわち、呼び出した側も，その例外に対する処理 （ “catch する” などの句で指示される） が特に指定されていない限り、 （呼び出しが行われた所で）その例外を投出し直した上で，その手続きを終了することになる。 †
2 種類の例外［
ECMAScript 言語束縛における， “例外の投出” の具体的な処理内容は、 WebIDL 仕様に 定義されている。 |
| RETURN [値] |
値 をアルゴリズムの呼び出し元に返した上で、 特に並列的に実行を継続するよう指示されていない限り，現在の手続きも終了することを意味する （下位手続きの中では、上位の手続きではなく，当の下位手続きを終了させる）。 呼び出し元のアルゴリズムにて，この返り値を指すときには、 通例， “〜した結果”, “〜の返り値” と記される。 値 を伴わない RETURN は：
|
日本語と英語には（特に文の構造に）大きな開きがあるので、 語彙以前に，原文を論理的に等価な言い回しに変形することも よくあります — 例えば，対偶をとるなど。 （挙げていくと際限ないが，実際には、 英語のすべての定冠詞（の有無, あるいは all, every, each 等々）, あるいは語形変化など、 およそすべて， “等価な” 言い回しに変形することになる。 双方の言語には，利用する語彙そのものに異なる視点が組み込まれているので、 より適する言い回しも，必然的に異なることになる。 単語の省略法も異なるので、 原文に無い語を補完したり，逆に原文の語を省略することも ときには必要になる。）
また、英語は動詞が中心的な意味を担う場合が多く、プログラミング言語で言い換えるなら， いくつかの callback 関数を入れ子にして記述するのに近い感がある （直訳的には、 “〜することを〜することを〜することを … 〜する” のように — 5 段くらい入れ子にされることも珍しくない — そのような入れ子の動詞（あるいは、形容詞として利用されている動詞）は、 主語や目的語, あるいはその両者が省略されていることも多い （事実上、英語の方が日本語より主語や目的語の省略は多いかもしれない））。 ついでに、英語の動詞（例： serialize ）は ある関数を実行すること, 動名詞 〜ing （例： serializing ）は 関数のある実行インスタンス, 動詞を語源とする名詞（例： serialization ）は 関数を実行した結果（あるいは関数の定義）に対応付られるような感もある。
マークアップや自動処理などの編集上の都合が，以下の原則より優先されている箇所も中にはあります。
仕様が規定するモデルの定義をより［ 明確化する／簡潔に述べる ］ため、 和訳では，明示的に定義用語とされていない語にマークアップを施したり, 新たな用語を導入することもあります。 例えば、ある語 X が，単独の個としての意味と いくつかの集合としての意味を兼ねて定義されることもよくある — 英文では， “X”, “Xs” のように単数形と複数形で自明に／慣用的に区別し得ても、 和文では， “X”, “X リスト” のように，明示的に分けて定義しないと不明瞭になることがある。
原文に含まれている情報を訳文の中に可能な限り正確に反映させるための一環として、 語彙とその対訳は、なるべく，一対一の対応関係† （より厳密には、 単語単位ではなく，句や意味構造の単位による対応関係） が保たれるようにしていますが、 仕様が扱う対象や技術的内容など，利用される文脈に依存するので （ときには仕様の編集者が好んで用いる表現にも）、 特に分野が異なる仕様間では，必ずしも統一されてはいません。 （† 一般に，一対一の対訳だけでは不足とされるが、 他所（同じ仕様の, あるいは関連する他の仕様）との 整合性をとる／関連性を断たないようにする必要もあるので，一対一をないがしろにするわけにもいかない）（ 一般的には、日本語／英語の単語をノードに見立てて，それぞれの言語の各単語の関係性を平面グラフに描いたとしたとき、 互いに双対グラフのような関係にあると考えた方がよいであろう。）
この種の重複は，同一仕様の中では（言い回しなども利用して）なるべく避けています （例： “get” ／ “fetch” ／ “obtain” ／ “retrive” ／ “aquire” ／ “achieve” … → “取得する” ／ “fetch する” ／ “得る” ／ “検索取得する” ／ “獲得する” ／ “達成する” … 等々） 。 多くの場合、 同じ対訳が用いられても形式的には特に問題ない所でも、 意味的／語源的／役割的に異なる含みが込められていたり，文脈を識別し易くする目的で 異なる語が利用されることも見受けられるので。 （もちろん，この種の厳密的な対応付けが必須になる場合も多いが、 当初は気付かなかった訳出の不足点を見つけたり, 後から修正する際にも役立つので。）
逆に，同じ語句に異なる表現を使い分けることは、比較的 多くなっています — （ “set” → “設定” ／ “集合” の様に原語自体が多義的に見える†ものに限られず） 例えば “match” → “合致”／“照合” や, “change” → “変更” ／ “変化” など （主題とされている対象から見て，その効果が能動的／受動的いずれになるかによっても，対訳が変わる／変わらざるを得ないことも） 。 しかしながら，逆に使い分けを抑制している場合もあります （例えば， “align” の対訳には “整列する”, “〜寄せ”, “揃える” などがあり，馴染まれている表現も文脈によって異なり得るが、 その様な場合でも，敢えて一つの表現に統一することがある。） （英語自体，同一の対象を様々な語彙で言い換える書き方が好まれる傾向もあり、 編集者によっては，その頻度が高いこともある — その場合、 ある程度 “正規化” して和訳しないと，何が “同じもの” を指しているのか不明瞭になり，読者を困惑させることになるであろう。） （† 多義的とは言い切れない面もある … 例えば、 設定 → 一定の何かが設定されているものの集まり，のような意味論上の関連性は考えられる。 同様の例として、 “load” の対訳には，動詞としての “読み込む” と名詞としての “負荷” の二つが挙げられるが、 英語話者にとっては，同じ概念に帰するのではないかと思われる。）
仕様間の対訳の不統一も，特に必要とされない限り避ける方針なので、 一部の語の対訳には多少の［ 冗長さ／不自然さ／馴染み難さ ］を感じる所はあるかもしれません。 （例えば “feature” の対訳に利用されている “特能（特色機能）” は， “機能” と訳されても特に問題ない箇所もあるが、 単なる “機能” 以上の含みもあるので， “function” などの対訳との衝突を避ける方を優先している。）
一部の用語には、 定訳が見当たらないなどの理由で訳者による対訳があてがわれていたり （その種の対訳は後で変更されるかもしれない）， カタカナ表記（外来語）に普及度が高くない漢字の対訳を用いています。
文脈が幅広い一般文章の中のカタカナ表記には、 次に挙げる利点が考えられますが：
ここでは，次に挙げる理由から、 漢字表記による［ 概念（あるいは用途／役割）の把握し易さ／ 関連の一般語との概念的な関わりの維持／ 記述の簡潔さ ］を多少優先しています：
例えば：
（その他、カタカナ利用の理由には，表現を婉曲にする（ “便所” → “トイレ” など）などもあるが、 その種の表現が仕様の文脈で必要になる場面は，通常ない。 しかしながら、 和語にすると無用に “生々しく” なることが多いのも， カタカナ語が増える理由にあると思われる。）
対訳では、［ 頻度が高い／通りがよい／長過ぎる ］などの理由で略語や原語そのままが利用されたり （例えば：
等々）、 原語のままにされる場合もあります — 例えば：
（どちらで表記しようが，専門的 難しさは変わらないなら、 略語／原語で記しても同じことであろう。）
無くても差し支えない所は省略する方針です（ 外来語（カタカナ）表記ガイドラインは無視している）： カタカナ表記の役割としての［ とりあえず近似的な発音で代用して記憶し易くする／原語スペルを復元し易くする ］観点からは、 大方，在っても無くてもさして変わらず、 カタカナ語（表音文字系の言語）は本来的に，文字数に比して短く一息に読まれる方が 文章のリズムは とり易く出来ているものと考えられるので。 また、多用されている全角ダッシュ（ “—” ）と紛らわしくなるのも避けたいので。 （長音無しを基準にとれば “省略” という言い方もおかしい？ 長音付きが好みの方は脳内変換で対応して下さい。 脳内変換に関して言えば、 長音［ 無し → 有り ］に 補完して 読む方が，［ 有り → 無し ］に 省略して 読むよりも馴染み易いのではないだろうか？）
例えば “ティ” で終わる語の語尾の長音は、 全般的に［ 長音の有無で意味が変わったり, 長音が省略された語の方だけ利用されない事例 ］は稀にしかないと思われるので，省略しています（ “プロパティ” など）。 動作の主体（動詞の変化形）を表す語尾の長音 （ “サーバー”, “ユーザー”, “パーサー”, “オブザーバー”, 等々） についても，大半は省略されています （仕様の中ではこの種のものが大勢を占める）。 （技術用語で長音が略される傾向が高いのには、 実在する動作者と抽象的な役割とを区別したいのも理由にあると思われる。 例えば，ソフトウェアの文脈における “ユーザ” は、 人利用者のみならず，利用者を代表して働く構成部品も含めて指している （あるいは実質的にそう見なせる／見なす必要がある）ことが多い。 “オブザーバー” と記されたときは，その種の役職に就いている人を指し、 “オブザーバ” と記されたときは，プログラミング パターンの一種を指すように感じることはないですか？）
上に挙げたページは翻訳なので二次著作物であり，その翻訳作業に関わる部分の著作権は翻訳者 （連絡先） に帰属することになりますが、 翻訳者はその利用について、原著作物の著作権に起因する制約を除き，次のとおりと定めます：
このページ自身, および
ページ一覧
に挙げられている各ページ, および
各ページに関連するリソース（スクリプト, 画像, 等々）
— すなわち，
https://github.com/triple-underscore/triple-underscore.github.io
の一覧リストに挙げられているもの —
は、
クリエイティブ・コモンズ 表示 - 継承 4.0 国際
ライセンスの下に提供されています。