編集（対訳統一（ procedure ）

Author: triple-underscore

Promises_Aplus-ja.html

@@ -153,7 +153,7 @@
 却下する:#reject
 充足され:#fulfill
 却下され:#reject
-	~promiseの解決~手順:#promise-resolution-procedure
+	~promiseの解決~手続-:#promise-resolution-procedure
 
 c.setTimeout:~HTMLGAPI#timers
 c.setImmediate:https://dvcs.w3.org/hg/webperf/raw-file/tip/specs//Overview.html#processingmodel
@@ -177,8 +177,6 @@
 	task-scheduling~queue
 trampoline::::トランポリン
 処理待ち:pending::~
-手順:procedure:手続き
-
 accessor::::アクセサ
 基盤:base:~
 循環的な:circular:~
@@ -685,7 +683,7 @@ <h3 title="The then Method">2.2 `then^es ~method</h3>
 			<li>
 %onFulfilled ／ %onRejected が`値$ %x を返したならば
 ⇒
-<a href="#promise-resolution-procedure">~promiseの解決~手順</a>：
+<a href="#promise-resolution-procedure">~promiseの解決~手続-</a>：
 <code>[[Resolve]](%promise2, %x)</code>
 を走らす。
 ◎
@@ -724,10 +722,10 @@ <h3 title="The then Method">2.2 `then^es ~method</h3>
 
 		</section>
 		<section id="promise-resolution-procedure">
-<h3 title="The Promise Resolution Procedure">2.3 ~promiseの解決~手順</h3>
+<h3 title="The Promise Resolution Procedure">2.3 ~promiseの解決~手続-</h3>
 
 <p>
-<dfn>~promiseの解決~手順</dfn>
+<dfn>~promiseの解決~手続-</dfn>
 は、`~promise$, および`値$を入力にとる抽象-演算であり、
 <span class="block"><code>[[Resolve]](%promise, %x)</code></span>
 と表記される。
@@ -996,7 +994,7 @@ <h2 title="Notes" data-cycling="a[href^='#note']">3. 注記</h2>
 まず
 <code>%x.`then^es</code>
 への参照を格納した上で，その参照を~testしてから，その参照を~callする
-］手順により、［
+］手続-により、［
 複数回にわたる
 <code>%x.`then^es</code>
 ~propertyへの~access

RFC6455-ja.html

@@ -507,8 +507,6 @@
 	読取n待ち:to be read
 	読取n中:reading
 	結果の:transformed
-	段:step
-	手続き:steps／procedure
 	成功-後:successful
 	成功~率:success rates
 	集合
@@ -2359,7 +2357,7 @@ <h3 title="Client Requirements">4.1. ~clientに課される要件</h3>
 
 <ol>
 	<li>
-~serverから受信された`応答~code$が `101$st でない場合、応答を~HTTP `HTTP$r の手続きに従って取扱う。
+~serverから受信された`応答~code$が `101$st でない場合、応答を~HTTP `HTTP$r の手続-に従って取扱う。
 特に，~clientは、`応答~code$ `401$st を受信した際には，認証を遂行し得る。
 ~serverは、`応答~code$ `3xx$st を利用して~clientを~redirectし得る（ただし，~clientがそれに追従することは要求されていない），等々。
 他の場合、次へ進む。
@@ -4642,7 +4640,7 @@ <h3 title="Normal Closure of Connections">7.3. 接続の正常な closure</h3>
 <p>
 ~serverは、欲されたときは, いつでも，~WebSocket接続を~closeしてヨイ。
 ~clientは~WebSocket接続を任意に~closeするベキでない。
-いずれの場合も、端点は`~WebSocket~closing~handshakeを開始する$手続き（ `7.1.2$sec ）へ移行して，~closureを起動する。
+いずれの場合も、端点は`~WebSocket~closing~handshakeを開始する$手続-（ `7.1.2$sec ）へ移行して，~closureを起動する。
 ◎
 Servers MAY close the WebSocket connection whenever desired. Clients SHOULD NOT close the WebSocket connection arbitrarily. In either case, an endpoint initiates a closure by following the procedures to _Start the WebSocket Closing Handshake_ (Section 7.1.2).
 </p>

RFC7230-ja.html

@@ -660,7 +660,7 @@ <h2 title="Introduction">1. 序論</h2>
 同様に `~server$も，各~clientの目的について意識する必要はない：
 ~HTTP要請は、［
 特定の型の~clientや,
-予め決定された手順を適用すること
+予め決定された手続きを適用すること
 ］に結付けられずに，他から隔離して考慮できる。
 その結果、多くの異なる文脈~下で ~protocolを効果的に利用でき、実装も，それらの文脈から独立に発展できるようになる。
 ◎
@@ -2528,7 +2528,7 @@ <h2 title="Message Format">3. ~message形式</h2>
 <div class="p">
 
 <p>
-~HTTP~messageを構文解析するための通常の手続きは、次の様になる：
+~HTTP~messageを構文解析するための通常の手続-は、次の様になる：
 ◎
 The normal procedure for parsing an HTTP message is to＼
 </p>
@@ -7636,7 +7636,7 @@ <h3>6.7. `Upgrade^h</h3>
 Hypertext Transfer Protocol 族
 ］に利用するための ~protocol名として， "`HTTP^c" のみを定義する。
 追加的な~tokenは，
-`8.6$sec にて定義される登録~手続きを利用して
+`8.6$sec にて定義される登録~手続-を利用して
 ~IANAにより登録される~OUGHT。
 ◎
 This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 2.6 and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure defined in Section 8.6.
@@ -8371,7 +8371,7 @@ <h3 title="Transfer Coding Registry">8.4. 転送~符号法~registry</h3>
 </p>
 
 			<section id="section-8.4.1">
-<h4 title="Procedure">8.4.1. 手続き</h4>
+<h4 title="Procedure">8.4.1. 手続-</h4>
 
 <p>
 登録にあたっては、次の~fieldを内包しなければナラナイ：
@@ -8545,7 +8545,7 @@ <h3 title="Upgrade Token Registry">8.6. `Upgrade^h ~token~registry</h3>
 </p>
 
 			<section id="section-8.6.1">
-<h4 title="Procedure">8.6.1. 手続き</h4>
+<h4 title="Procedure">8.6.1. 手続-</h4>
 
 <p>
 登録-済みの各~protocol名は、［
@@ -8614,7 +8614,7 @@ <h4 title="Procedure">8.6.1. 手続き</h4>
 </ol>
 
 <p>
-HTTP Upgrade Tokens 用の，この登録~手続き
+HTTP Upgrade Tokens 用の，この登録~手続-
 以前に `2817-7.2$rfc にて定義されたものを置換する。
 ◎
 This registration procedure for HTTP Upgrade Tokens replaces that previously defined in Section 7.2 of [RFC2817].

RFC7231-ja.html

@@ -1134,7 +1134,7 @@ <h5 title="Media Type">3.1.1.1. ~MIME型</h5>
 </pre>
 
 <p>
-~MIME型は、`BCP13$rにて定義される手続きに則って，~IANAにより登録される~OUGHT。
+~MIME型は、`BCP13$rにて定義される手続-に則って，~IANAにより登録される~OUGHT。
 ◎
 Internet media types ought to be registered with IANA according to the procedures defined in [BCP13].
 </p>
@@ -1171,7 +1171,7 @@ <h5 title="Charset">3.1.1.2. ~charset</h5>
 】</p>
 
 <p>
-~charset名は、`2978$Rにて定義される手続きに則って，~IANA
+~charset名は、`2978$Rにて定義される手続-に則って，~IANA
 <a href="~IANA-a/character-sets">Character Sets</a>
 ~registryに登録される~OUGHT。
 ◎
@@ -2104,7 +2104,7 @@ <h3 title="Payload Semantics">3.3. ~payloadの意味論</h3>
 	<li>
 ~error状態s~codeを伴う応答~messageが包含する~payloadは、通例的に，［
 その~error状態, および
-その解決に示唆される次に行う手順
+その解決に示唆される次に行う手続き
 ］について述べるような，~error条態を表現する。
 ◎
 Response messages with an error status code usually contain a payload that represents the error condition, such that it describes the error state and what next steps are suggested for resolving it.
@@ -8120,7 +8120,7 @@ <h3 title="Method Registry">8.1. ~method~registry</h3>
 </p>
 
 			<section id="section-8.1.1">
-<h4 title="Procedure">8.1.1. 手続き</h4>
+<h4 title="Procedure">8.1.1. 手続-</h4>
 
 <p>
 ~HTTP~method登録は、次の~fieldを内包しなければナラナイ：
@@ -8349,13 +8349,13 @@ <h3 title="Status Code Registry">8.2. 状態s~code~registry</h3>
 
 <p>
 この節は、
-以前に`2817-7.1$rfcにて定義された HTTP Status Codes 用の登録~手続きを置換する。
+以前に`2817-7.1$rfcにて定義された HTTP Status Codes 用の登録~手続-を置換する。
 ◎
 This section replaces the registration procedure for HTTP Status Codes previously defined in Section 7.1 of [RFC2817].
 </p>
 
 			<section id="section-8.2.1">
-<h4 title="Procedure">8.2.1. 手続き</h4>
+<h4 title="Procedure">8.2.1. 手続-</h4>
 
 <p>
 登録は、次の~fieldを内包しなければナラナイ：
@@ -8955,7 +8955,7 @@ <h3 title="Content Coding Registry">8.4. 内容~符号法~registry</h3>
 </p>
 
 			<section id="section-8.4.1">
-<h4 title="Procedure">8.4.1. 手続き</h4>
+<h4 title="Procedure">8.4.1. 手続-</h4>
 
 <p>
 `内容~符号法$の登録にあたっては、次の~fieldを含めなければナラナイ：
@@ -9352,7 +9352,7 @@ <h3 title="Browser Fingerprinting">9.7. ~browser指紋収集</h3>
 ］を
 — 利用者が，他の形の~data~collection（例：~cookie）に対しては持ち得るような、対応ng制御なしに —
 可能化するので、~privacy懸念と見なされる。
-多くの一般用~UA（すなわち，~web~browser）は、指紋収集を抑制する手順を踏んでいる。
+多くの一般用~UA（すなわち，~web~browser）は、指紋収集を抑制する手続きを踏んでいる。
 ◎
 Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. These characteristics might include information related to its TCP behavior, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time without the corresponding controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints.
 </p>

RFC7233-ja.html

@@ -1472,7 +1472,7 @@ <h3 title="Range Unit Registry">5.1. 範囲~単位~registry</h3>
 </p>
 
 			<section id="section-5.1.1">
-<h4 title="Procedure">5.1.1. 手続き</h4>
+<h4 title="Procedure">5.1.1. 手続-</h4>
 
 <p>
 HTTP Range Unit の登録は、次の~fieldを含まなければナラナイ：

RFC7234-ja.html

@@ -3394,7 +3394,7 @@ <h3>5.5. `Warning^h</h3>
 以下の `warn-code$p が，この仕様により定義される。
 それぞれには、推奨される英語の `warn-text$p, および
 その意味の記述が伴われる。
-追加的な `warn-code$p を定義するための手続きは、`7.2.1$secにて述べる。
+追加的な `warn-code$p を定義するための手続-は、`7.2.1$secにて述べる。
 ◎
 The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in Section 7.2.1.
 </p>
@@ -3536,7 +3536,7 @@ <h3 title="Cache Directive Registry">7.1. ~cache指令~registry</h3>
 </p>
 
 			<section id="section-7.1.1">
-<h4 title="Procedure">7.1.1. 手続き</h4>
+<h4 title="Procedure">7.1.1. 手続-</h4>
 
 <p>
 登録にあたっては，次の~fieldが含まれなければナラナイ：
@@ -3697,7 +3697,7 @@ <h3 title="Warn Code Registry">7.2. `warn-code^p ~registry</h3>
 </p>
 
 			<section id="section-7.2.1">
-<h4 title="Procedure">7.2.1. 手続き</h4>
+<h4 title="Procedure">7.2.1. 手続-</h4>
 
 <p>
 登録にあたっては，次の~fieldが含まれなければナラナイ：

RFC7235-ja.html

@@ -934,7 +934,7 @@ <h3 title="Authentication Scheme Registry">5.1. 認証~scheme~registry</h3>
 </p>
 
 			<section id="section-5.1.1">
-<h4 title="Procedure">5.1.1. 手続き</h4>
+<h4 title="Procedure">5.1.1. 手続-</h4>
 
 <p>
 登録にあたっては，次の~fieldを含まなければナラナイ：
@@ -985,7 +985,7 @@ <h4 title="Considerations for New Authentication Schemes">5.1.2. 新たな認証
 基づく／束縛される
 認証は、この仕様の視野~外であり、［
 その接続が、認証-済み利用者~以外のどの主体からも利用され得ない
-］ことを確保するための手順が踏まれない限り，内来的に欠陥があるものとされる（ `7230-2.3$rfc を見よ）。
+］ことを確保するための手続きが踏まれない限り，内来的に欠陥があるものとされる（ `7230-2.3$rfc を見よ）。
 ◎
 • HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 2.3 of [RFC7230]).
 </li>

RFC723X.js

@@ -1014,8 +1014,6 @@ app:application:::アプリケーション
 根本的:fundamental:~
 欠如:lack:~
 欠如する:lackする:欠く
-手続き:procedure:~
-手順:steps:~
 採用-:adopt:~
 採用:adoption:~
 推測-:guess:~

common0.js

@@ -2260,6 +2260,7 @@ method::::メソッド
 段:step:~
 手続き:steps:~
 下位手続き:substeps:~
+手続-:procedure:手続き
 呼出され:invokeされ:呼び出され
 呼出さな:invokeしな:呼び出さな
 呼出す:invokeする:呼び出す

css-color-ja.html

@@ -1344,7 +1344,6 @@
 強制d:forced:強制
 組織化-:organize:~
 	組織化-:organization
-手続-:procedure:手続き
 実験結果:experimentation:~
 続行-:proceed:~
 衝突-:clash:~