このページは、 Web プラットフォーム関連の様々な仕様の日本語訳の一覧と， それらの日本語訳に共通な事項についての説明です。
これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、 日本語訳は公式なものではありません。 誤訳が無いことは保証されません。 ［ 当の仕様の策定者たちが想定している／当の仕様に期待されている ］意味論を完全かつ正確に反映することは保証されません。 翻訳なので、 語彙レベルで原文と正確に一致する意味を表すことは決してありません。 日本語は自然言語なので、 誰がいつどこで読んでも同じ解釈になることは保証されません。 ）（ 実際に誤訳が見つかることも時折あります。 それらについては見つかり次第修正され， 加えて用語の対訳や言い回しなども時折修正されるので、 これらの翻訳が「完成」する日は永遠に来ません。 逆に原文仕様が誤っていることもあり、 明白な誤りと見受けられるものなど，日本語訳にて修正している箇所もあります。
一部の仕様は日々更新され続けているので、 日本語訳は最新版と一致していないこともあります — 特に， WHATWG による Living Standard （ “生きた標準” ）／ W3C による Editor's Draft （ “編集者草案” ）。 原文の更新に伴う和訳の更新の際に，取り込み漏れがあるかもしれません。 その完全性は保証されませんが、 ツールを利用して不定期に検証してはいます — 多数の更新が積み重なったときなど （ RFC 文書, W3C 勧告については、 原文の更新は無いので，原文テキストとの差分は検査済み）。
ほとんどのページは、 スクリプトのサポートと有効化（ ES 6 以上）が必須です — タイトルを除く内容すべてがスクリプト（ JavaScript ）により生成されているので （この背景色のものだけそうでない）。 ［ CSS ／ DOM ／ HTML ］のサポートが古いブラウザでは、 表示が崩れたり，一部の機能が働かないかもしれません。 古過ぎるブラウザ（すべての IE を含む）では表示すらされないでしょう — 他のブラウザをご利用ください。
ほぼすべてのページは、
仕様のメタ情報を，タイトルの下に 次のようなクリックで開閉できる UI （ details 要素）で呈示しています：
ここには、 当の日本語訳が元にしている原文についてや, 定型的な事項など，翻訳に関するメタ情報が記される。
ここには、 原文の冒頭に記されているメタ情報が，ほぼそのまま記される。 原文やその更新履歴, メーリングリスト, テスト一式, 実装報告, その他を指す URL など。 便宜のため、［ 原文に記されていない／他所に記されている ］メタ情報を追加することもある。
ここには、 原文の著作権情報が記される （が、仕様によっては，他所に記されることもある）。
ここには、 仕様内に記された課題（ issue ）, 定義されている IDL やプロパティ, 等々 を巡回するための UI が示される （多くの原文には，それらに対応する索引節があるが、 和訳では省略して このような UI に代えている）。
Github リポジトリ から全ファイルを一括ダウンロードできます（冒頭にある "Clone or download" から "Download Zip" を選ぶ）。
（原文日付： — 個々のページに示される これより過去の原文日付は、 この日付まで，概ね（有意な）更新は無いことを表す。 ）
html 要素 ／
文書メタデータを与える要素（
title,
link,
meta
など）
section,
article,
nav,
h1
など）
main,
div,
p
など）
a,
dfn,
q,
em など）
link,
a,
area,
form
用の各種オプション）
ins,
del ）
picture,
source,
img
）,
画像マップ（
map,
area
）
iframe,
embed,
object,
param
要素, MathML, SVG
video,
audio
）
track 要素：
メディア要素用のテキストトラック
table,
tr,
td
など）
input 要素）
input 以外の要素）：
各種フォームコントロール
（ form, button, select など）
details,
summary,
dialog ）, コマンド
script,
noscript,
template,
slot
要素
canvas 要素
hidden 属性, フォーカス処理, アクセスキー, 編集
popover 属性
ナビとセッション履歴に関係する API（ § APIs related to navigation and session history ）
Window, § Location, § History 他：
古典的な API ／ Window オブジェクト
Navigation インタフェース）
WindowProxy 他
Document オブジェクトの作成と破壊
§ Dynamic markup insertion, § DOM parsing and serialization APIs：
document.open(), document.write() など）
innerHTML, outerHTML, insertAdjacentHTML など）
Navigator オブジェクト／
様々なスキーム用のカスタムハンドラなど
メッセージ通信（ § Communication ） ¶
Pointer Events — Level 4： マウス, タッチ, ペン などの様々なポインタ指示装置によるイベントを統一的に扱う
（旧バージョン（ Level 2 勧告）の和訳もある。）
中核仕様：
試験的な HTTP 拡張仕様：
WebTransport — 多重化されたプロトコル（ HTTP/3, HTTP/2 ）越しの双方向通信：
WebSocket — HTTP/1.1 越しの双方向通信：
DOMHighResTimeStamp ）,
計時の基準
requestIdleCallback()：
時間を要するタスクを，時間に厳しい他のタスクを阻まずに実行する
sendBeacon() メソッド
— 文書の unload 時にサーバに向けて非同期にデータを送信する
@import 規則 ／
カスケード層（ @layer 規則）
@scope 規則
progress(),
mix(),
first-valid(),
toggle(),
attr(),
random(),
sibling-index(),
等々）
@function 規則
@namespace 規則
&
位置決めスキーム（絶対位置決め他）, 多層化：
contrast-color() 関数（ Level 5 ）に対する拡張／
color-layers() 関数
SVG Native： ネイティブアプリ用の SVG プロファイル
<?xml-stylesheet …?> ）
名前,
定義リストの見出し,
参照文献の見出し,
等々）。
次が含まれたパネルが表示される：
リンクテキストには、 章／節 の見出しについては その原文，他の場合は その項目の id が示される。
このリンクは、 和訳に限り id が付与されている項目に対しては示されない。 また、自動処理の都合などから、 原文と異なる id が付与されている項目もあるが、 その場合でもリンクは元の id を指すようにしている （逆に，和訳ページが元の id でアクセスされた場合も同様）。
実装状況や用例など、 Web 開発者向け情報。 該当するページが MDN サイトに実際にあっても， 和訳には まだ付与していないものもある（随時更新）。 また，対応する項目が複数ある場合でも、 （現時点では，代表的な） 1 個しか示されない。
“原文”, “MDN” を指すリンクは、 新たなタブ（またはウィンドウ）内に開かれ， それ以降も同じタブが再利用される （再利用させたくない場合、 文脈メニューなどを介して，明示的に指示する必要がある）。
対訳切替など，一部機能は省略されているページもあります。
以下に述べる表記規約は原則であり，ページ間で多少異なることもあります。
リンクは、次の３種の下線スタイルで呈示されます：
英文仕様を指すリンクのうち一部では、［ マウスを重ねたとき／フォーカスしたとき ］に，リンク先文書の【日本語訳】へのリンクも追加で表示されます （日本語訳はバージョンが異なっていたり，部分訳の場合もあります） 。
見本コードなどのコードブロック（ pre ）において，
可用な幅に収まり切らない行は、
自動改行して呈示されます。
同様に，可用な幅に収まり切らない画像は、
収まるよう縮小して呈示されます。
その他のスタイルは、 原文のそれを残しているものもあれば， まったく違えているものあります。 例えば、 マージンや行間を日本語に適したスタイルに改めたり， 各 仕様で一貫するよう別のスタイルに置換するなど。
基本的には，原文に即する様にしてありますが、 次に挙げる理由から，利用するマークアップ構造を改めている箇所もあります：
日本語と英語の［ 資質／約束事 ］の違いに由来するもの — 例えば：
<var> タグが利用される）
は多用される。
そのまま訳すと文脈から自明でなくなる指示代名詞に対しても、
同様に多用される。
これらが翻訳結果の構成に大きく反映され、 見かけ上，原文と乖離する場合もときどきあります。
［ 曖昧さや多義性を抑制する／視認性を改善する ］目的で、 句読点, 記号, 括弧類, その他の約物は積極的に利用しています （ 2 種類の読点の混在など，日本語の一般的慣習を意図的に破っている用法もあります） 。 これらは、 仕様が対象にしている分野に関する知識や意味論に通じていない状態でも［ 文脈から推定する労力を軽減し, 内容を正確に読み取り易くする ］ためのものであり†，必ずしも［ 文法的な厳密さ（解釈が常に機械的に一意に定まる，等）を備えている／ 適用可能な所には常に利用している／ 全ページで完全に統一されている ］とは限りません：
（† また，訳者の［ 理解度／翻訳意図 ］をより鮮明に表すものでもあるので、［ 解釈／翻訳 ］に誤りがあれば，それをより鮮明に示すことになる — 例えば，角括弧の用法： 英語の句 “strong X or Y” の解釈は、 文脈に依存して， “［ 強い X ］または［ Y ］” が意図されている場合もあれば， “強い［ X または Y ］” が意図されている場合もある。）
| 記号 | 説明／用法（原則） |
|---|---|
| 隅付き括弧 【, 】 | 訳者による【注釈／原文の補完】。 |
| 全角 丸括弧 （, ） | 後述の全角ダッシュとは対照的に、 主として，補助的な説明や例を挿入するために利用される （例えば、この括弧内に記した句のように）。 |
| 半角 丸括弧 (, ) | 主として，地の文の中で、 アルゴリズムの入力引数, あるいは数式を括るときに利用される。 （全角と見た目の区別が付きにくいが、文脈から容易に判別できるであろう。） |
| 全角 角括弧 ［, ］ | 修飾や条件などの対象範囲を明確化するための括り。 例えば、 ［［列挙された多数の語句］や長い語句］を文の中で一体として扱うとき， あるいは 読点の結合順位（後述）だけでは不足する場合など （例えばこの文では、 内側の ［, ］により “列挙された” が “長い語句” にかからないようにした上で， “一体として扱われる” 対象を明確化するために外側の ［, ］で括っている）。 特に必要がない所でも，同じパターンが繰り返されるときは、 パターンを強調するために利用されることがある。 また、長文の構造を読み取り易くする際にも利用される。 （これは、［ 話し言葉のように一息に話すことにより，ひとまとまりを表現するような柔軟性 ］を，多少なりとも書き言葉に付与するためのものでもある。 また、 書き言葉であるからして，発音できない各種記号を使わない手はないであろう — 語句の順序を 論理的な流れを追い易いものに保ちつつ，曖昧さを排除するためにも。 厳密さを追求するなら、 記号に頼らず，あらゆる関係構造をマークアップに落とし込んだ上で， CSS で呈示に反映させるのが理想であろうが。） |
| 全角コロン "：" | コロンの前の語句に，後続の文やブロックでその説明や定義を与える（特に，説明が長くなる場合）。 |
| 句点 "。" | 句点は "。" に統一。 |
|
全角読点 "、", 全角カンマ "，", 半角カンマ "," | 結合度の低い順に，左の３種類が読点として利用される。 結合度が全角読点の一種類で済む場合でも、 連続性が強い所では，カンマが利用される。 また，半角カンマ（＋半角スペース）は、 文脈の中で等格な［ 語句／キーワード ］を列挙する際に特に利用される。 （これらは，実質的に “［, ］” の略記と見なせることが多い。） |
| 全角ダッシュ " — " | この文のように，長めの語句を挿入する所 — 丸括弧が補助的な説明を挿入するのとは対照的に，規範的な語句を挿入するときなど — では、 2 個のダッシュで括られる。 この文のように，二つの文の関連性を明示する所では、 1 個のダッシュで繋げられる — 最初の文を句点で区切る代わりに。 （全角ダッシュ文字には U+2015 ( HORIZONTAL BAR ) ではなく, U+2014 ( EM DASH ) が利用される。） |
| 全角スラッシュ "／" |
複数表現を孕む場合、 角括弧による表記法の相違に注意されたし。 例えば、 “ N 個の［英字／数字］からなる” と記された所では，英字と数字が混在し得ることを表す一方で、 “［ N 個の英字／ N 個の数字 ］からなる” と記された所では，英字か数字どちらかのみからなることを表す。 |
| 半角スペース | “小さな” 区切り：
|
|
二重引用符： （曲線型） “…” （半角） "…" | “曲線型” の方は、 通常の引用符 （説明用の［ 比喩的／概念的 ］な記述など）。 “半角” の方は、 仕様が規定するリテラルや記号類, 例示コード類の括りなど， 意味よりも文字列そのものの［ 同一性／忠実さ ］が重視される所で利用される。 |
これらの記号を多用する理由は、 （前提として多義的に解釈されては困る）仕様の記述には，次に挙げるような資質があるため、 文脈から意味構造を一義的に決定するのが難しくなる傾向があることによる （例えば 「黒い目のきれいな女の子」 ）：
どの和訳においても、 要件レベルを表す語句には，次に挙げる対訳を利用しています：
| 原語 | 対訳 | 要件レベル |
|---|---|---|
| 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)／ 省略時は〜 (*5) | (c) |
この表の要件レベル列の：
これらの要件が課される主体は、 IETF 文書（ RFC や Internet-Draft など）においては，一般にネットワーク通信の参加者 （クライアント, サーバ, プロキシなど） であり、 他の文書においては，概ね次に分類される：
実装者： web 内容を消費して動作するソフトウェア — ほとんどは、 web ブラウザなどの UA を指すが，適合性検査器なども含まれる。
UA は， user agent の略称であり、 和訳においては，常に この略称で表記される。
原則として、 上に挙げた以外の対訳は利用していません(*6) 。 逆に、 他の句に上に挙げた対訳を利用することも避けています。 ただし，小文字の “must” 等は、 これらの語に大文字表記（またはマークアップ）を［ 利用していない仕様 ／ 利用していないが RFC 2119 の意味の下で利用されていると考えて差し支えない所 ］では、 マークアップを施さないまま，同じ対訳にしています。
多くの仕様では，以下に挙げる慣用句を利用しています（括弧内は原文の表現）：
この句には、 一般に，次が含意される：
Foo として指示される場合、
O は “Foo オブジェクト” と称されることが多い
— この場合、
C は Foo インタフェースを実装するオブジェクトの集合を表すことになる。）
より形式的に述べるなら、 次のように規定されると解釈すればよいであろう：
C に属する任意の個体 O に対し，次の両者を満たすような個体 V がただ一つ存在する：
そのような V を指すときは、 “ O に結び付けられている P ”, あるいは単に “ O の P ” とも記される。
仕様には明文化されないことが多いが、 この結び付けは “専属的” な関係を含意することもある — すなわち， P に属する所与の個体 V に対し，関係 < C, P > を満たす C に属する個体 O は、 あっても 1 つに限られる。 一方で，該当しない場合もあり、 この区別は文脈から判断する必要がある。
ol 要素）の中のリスト項目（ li 要素）で表現される 1 個のブロック（入れ子階層の末端ブロックに限らず）。
例えば “前段” は、
その “前段” と記されたブロックと同じ階層レベルにおいて その直前にあるブロックを指す。
（ “手続き” は “procedure” の定訳でもあるが、
この語が現れる仕様は，ごく限られる
— 実質的に同義なので、
和訳では同じ対訳を利用している。）
手続きは、 他の手続きの中に入れ子にされることもある。 ある手続き（ “上位手続き” ）の中に入れ子にされた一連の段が成すブロックは、 その冒頭に “手続き” を含んでいる句（例： “次の手続きを遂行する…” ）を伴うとき， 入れ子にされた手続き（ “下位手続き” ）であることを指示する。 加えて、並列的に遂行するよう指示されたブロックも，暗黙的に入れ子にされた手続きと見なされる。 入れ子にされた手続きは、 上位手続きの引数や その中で宣言された変数をそのまま参照するが、 その中に現れる RETURN （次節を見よ）は， 当の手続きのみを終了させる （値を返すものは、上位手続きに結果を返す） （ JavaScript のクロージャ関数（関数内に定義される関数）と同様にふるまう）。
foo() メソッド手続きは…”
（以下, 手続きの内容が後続する）
foo 手続きfoo に対する
“foo 手続き”
のような句は、
foo のふるまいを定義している手続きを指す。
foo が IDL 属性の場合、
手続きには取得子, 設定子の両方があり得るので，［
“foo 取得子手続き” ／
“foo 設定子手続き”
］のように記される。
ここでの 引数 は、 当のメソッドに宣言された引数であって，次をすべて満たすことが前提にある：
optional が付与されている
）
そのような引数に明示的に JavaScript undefined 値を渡してメソッドを呼び出した場合も、
missing に解釈されることになる。
（可変個引数（宣言に "..." が付与されたもの）に渡された undefined は、
必須の引数と同様に解釈される。）
（†省略可能な引数のうち， "= 既定値" が宣言されているものは、
その引数を省略した場合，既定値として 既定値 を渡したものと見なされる。）
仕様の中のアルゴリズムは、 有順序リストの入れ子階層によるマークアップにより， 一般的なプログラミング言語と同様な［ 実行順序, 制御構造 ］が表現されています。
多くの仕様の和訳では、 アルゴリズムの中の定型的な記述を簡明に, かつ一貫させるため、 いくつかの記号や表記法を導入しています （個別の仕様ごとに，追加の記号が導入されることもあります）：
次に挙げる記号についての説明は、前節を参照されたし： ∧, ∨, ¬ ＝ ≠, ε, +, −, ×, ÷ >, ≥, <, ≤, 〜
| 表記 | 意味 |
|---|---|
| Assert：条件 | いわゆる表明。 条件 で表現される暗黙的な不変則を明示的に示して， アルゴリズムの明確化を図るものであり、 アルゴリズムの意味論に要件を追加するものではない。 アルゴリズムの入力が満たしているはずの条件が記されることが多い。 |
| これ° |
IDL this 値 の略記。 論の対象のインタフェース（インタフェース mixin も含む）のメンバ （メソッド／属性取得子／属性設定子）が呼び出されているオブジェクト自身 — その種のメンバを定義しているインタフェースを実装している，ある特定のインスタンス — を指す（ JavaScript の “this” に ほぼ対応するが，定義は異なる）。 ほとんどの場合、当のメンバのふるまいを定義するアルゴリズムの中で利用される。 構築子手続きの中でも利用され、 当のインタフェースを実装する新たなインスタンスを指す。 この用語は頻出し，原文では単に “this” と記されることが多いが、 日本語的にすわりが悪いので （および JavaScript の this と混同されないよう）， 和訳では これ° と表記される。 |
| アルゴリズム名( 引数… ) |
アルゴリズム名 が指示する手続きを 引数 （ 0 個以上）を渡して適用することの略記。 引数 として "↓" が記された所では （例： “アルゴリズム名( ↓ )” ）、 引数たちは直後のブロックに（概して， 1 行に 1 個ずつ）列挙されることを表す （この表記は、［ 引数の個数が多い／ いくつかの引数は 長い注釈を伴うか名前が長い ］ときに，複数行に分けて可読性を改善するために利用される）。 |
O 上の foo 手続き( 引数… )
|
IDL メンバ foo を実装しているオブジェクト O 上で，
foo 用に定義された手続きを
— 所与の 引数 （ 0 個以上）を渡して —
適用することの略記。
その手続き内の これ° は、
O を指すことになる。
|
| 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 はその量を与える。 |
| IS 条件 |
条件 を評価した結果を表現する真偽値を返す。 すなわち、 条件 が［ 満たされるならば true ／ 満たされないならば false ］になる。 |
| 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 する” などの句で指示される） が特に指定されていない限り — （呼び出した箇所で） その例外を投出し直した上で，自身の手続きを終了することになる。 †
3 種類の例外
— 単純例外,
ECMAScript 言語束縛における例外の投出法を成す具体的な処理は、 Web IDL 仕様に定義されている。 |
| RETURN [値] |
値 をアルゴリズムの呼び出し元に返した上で、 特に並列的に実行を継続するよう指示されていない限り，現在の手続きも終了することを意味する （入れ子にされた手続きの中では、 当の手続きのみを終了させる — 上位の手続きではなく）。 呼び出し元のアルゴリズムにて，この返り値を指すときには、 通例， “〜した結果”, “〜の返り値” と記される。 値 を伴わない RETURN は：
|
日本語と英語には（特に文の構造に）大きな開きがあるので、 語彙以前に，原文を論理的に等価な言い回しに変形することも よくあります — 例えば，対偶をとるなど。 （挙げていくと際限ないが，実際には、 英語のすべての定冠詞（の有無, あるいは all, every, each 等々）, あるいは語形変化など、 およそすべて， “等価な” 言い回しに変形することになる。 双方の言語には，利用する語彙そのものに異なる視点が組み込まれているので、 より適する言い回しも，必然的に異なることになる。 語の省略法も異なるので、 原文に無い語を補完したり，逆に原文の語を省略することも ときには必要になる。 特に、 英文における［ 単語を分離するスペース ］の対訳として，日本語の助詞（特に “の” ）が利用されることは多い — ときには、 スペースを挟む 2 つの語の関係性を明示的に補完しないと，日本語として［ 意味が通らなくなる／誤解を招く表現になる ］ことすらある。）
また、英語は動詞が中心的な意味を担う場合が多く、プログラミング言語で言い換えるなら， いくつかの 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 国際
ライセンスの下に提供されています。