[streams] 諸々の編集（言い回し

Streams-ja.html

@@ -1092,8 +1092,11 @@
 側:side:~
 入出力:I/O:~
 静止-:pause::~
-close:::::クローズ
-open::::オープン
+open:
+close:
+closing:
+	~closeし終える:closing down／finishes closing
+closure:
 	closed:
 	errored:
 	~cancel:::::キャンセル
@@ -1133,9 +1136,6 @@
 給-:supply:~
 shutdown:
 shut-down:shut down
-closing:
-	~closeし終える:closing down／finishes closing
-closure:
 into:
 	~pull~into:pull-into
 sentinel:::番
@@ -1391,7 +1391,6 @@
 自己検分:introspection:~
 述語:predicate:~
 構う:worryする:~
-控えめ:sparing:~
 refactor::::リファクター
 	refactoring
 統一化-:unify:~
@@ -1409,6 +1408,7 @@
 	interference
 集中-:centralize:~
 注力-:concern:~
+	割かれて:concern
 続行-:proceed:~
 素通り:bypass:~
 浪費-:waste:~
@@ -1480,7 +1480,7 @@
 	上述とは別方向の:go in the other direction
 	〜は別として:apart from
 	意図nの下で:with the intention that
-	~~誘因:driver
+	要する〜~~誘因:driver
 	-:which mean to
 	〜から導出された:-derived
 	〜が供した:-provided
@@ -1566,13 +1566,13 @@
 	ときには、:sometimes
 	より巧妙:subtle
 	なおさら:Even more so than
+	控える:sparing
 	さもなければ:otherwise
 	主に:mainly
 	上層に重ね:layered on top
 	~promiseを返す〜:promise-returning
 	まだ仕様~化されていない:still-being-specified
 	~~実際に:in fact
-	割かれて:concern
 	かなりの部分:much of
 	当の:in question
 	類の:sort of
@@ -2907,7 +2907,7 @@ <h3 title="Using readable streams">4.1. 可読~streamの利用-法</h3>
 ほぼ教育的であることに注意。
 実用的な目的においては、
 `read()$byob ~method用の `min$brO ~optionが，
-正確な~byte数を読取るための もっと容易かつ直接的な仕方を供する：
+正確な~byte数を読取るための もっと容易かつ直な仕方を供する：
 ◎
 Note that this example is mostly educational. For practical purposes, the min option of read() provides an easier and more direct way to read an exact number of bytes:
 </p>
@@ -23116,12 +23116,12 @@ <h3 title="Miscellaneous">8.3. 諸々の演算</h3>
 <h2 title="Using streams in other specifications">9. 他の仕様における~streamの利用-法</h2>
 
 <p>
-この標準のかなりの部分は、
+この標準を成すかなりの部分は、
 ~streamの内部的な機構に割かれている。
 他の仕様は、
 一般に，これらの詳細~について構う必要はない。
 代わりに，他の仕様は、
-この標準が定義する様々な~IDL型を介して，以下に挙げる定義に沿って，
+それが定義する様々な~IDL型を介して, および以下に挙げる定義に沿って，
 この標準と~interfaceするベキである。
 ◎
 Much of this standard concerns itself with the internal machinery of streams. Other specifications generally do not need to worry about these details. Instead, they should interface with this standard via the various IDL types it defines, along with the following definitions.
@@ -23552,11 +23552,12 @@ <h4 title="Creation and manipulation">9.1.1. 作成と操作</h4>
 <hr>
 
 <p>
-以下に与える~algoは、
+以下に与える~algoは、［
 上の［
 `設定しておく$RS／
 `~byte読取り~support付きで設定しておく$RS
-］~algoを介して初期化されたもの以外の `ReadableStream$I ~instance
+］~algoを介して初期化されたもの
+］以外の `ReadableStream$I ~instance
 （例：~web開発者が作成した~instance）には，利用してはナラナイ。
 ◎
 The following algorithms must only be used on ReadableStream instances initialized via the above set up or set up with byte reading support algorithms (not, e.g., on web-developer-created instances):
@@ -23801,9 +23802,8 @@ <h4 title="Creation and manipulation">9.1.1. 作成と操作</h4>
 <hr>
 
 <p>
-以下に与える各~algoは、
-上の［
-`~byte読取り~support付きで設定しておく$RS~algoを介して初期化されたもの
+以下に与える各~algoは、［
+上の`~byte読取り~support付きで設定しておく$RS~algoを介して初期化されたもの
 ］以外の `ReadableStream$I ~instanceには，
 利用してはナラナイ。
 ◎
@@ -23904,9 +23904,7 @@ <h4 title="Creation and manipulation">9.1.1. 作成と操作</h4>
 それは、
 保守的であり，
 %~byte列 内に【一部の】~byte列を残すことに注意
-— %~byte列 から【全部を】積極的に`~chunkを~enqueueする$RSのではなく
-【この~algoは、 入力 %~byte列 を改変する】
-。
+— %~byte列 から【全部を】積極的に`~chunkを~enqueueする$RSのではなく。
 なので、
 この~algoの~call元は，残りの~byteたちの個数を`背圧$用の通達として利用するよう求めることもあろう。
 ◎
@@ -23924,6 +23922,12 @@ <h4 title="Creation and manipulation">9.1.1. 作成と操作</h4>
 ◎
 To pull from bytes with a byte sequence bytes into a ReadableStream stream:
 </p>
+
+<p class="trans-note">【
+この~algoは、
+入力 %~byte列 を改変する。
+】</p>
+
 <ol>
 	<li>
 ~Assert：
@@ -24193,10 +24197,10 @@ <h4 title="Reading">9.1.2. 読取n法</h4>
 %読取器 は，それに対応している `ReadableStream$I に対し排他的な~accessを是認するので、
 読取る方法を成す実際の仕組みは，観測され得ない。
 実装は、
-自身に好都合な もっと直接的な仕組みも利用できる。
+自身に好都合な もっと直な仕組みも利用できる。
 `ReadableStreamDefaultReader$I に代えて
 `ReadableStreamBYOBReader$I を獲得して利用するか，
-各~chunkに直に~accessするなど。
+各~chunkに対し直に~accessするなど。
 ◎
 Because reader grants exclusive access to its corresponding ReadableStream, the actual mechanism of how to read cannot be observed. Implementations could use a more direct mechanism if convenient, such as acquiring and using a ReadableStreamBYOBReader instead of a ReadableStreamDefaultReader, or accessing the chunks directly.
 </p>
@@ -24296,7 +24300,8 @@ <h4 title="Introspection">9.1.3. 自己検分</h4>
 他の仕様は，代わりに
 `§ 読取n法＠#other-specs-rs-reading$
 に与える~algoを利用するベキである
-（例えば，当の~streamは`読取n可能$RSかどうか~testする代わりに、
+（例えば、
+当の~streamは`読取n可能$RSかどうか~testする代わりに，
 その`読取器を取得-$RSして例外を取扱うよう試みて）。
 ◎
 The following predicates can be used on arbitrary ReadableStream objects. However, note that apart from checking whether or not the stream is locked, this direct introspection is not possible via the public JavaScript API, and so specifications should instead use the algorithms in § 9.1.2 Reading. (For example, instead of testing if the stream is readable, attempt to get a reader and handle any exception.)
@@ -24305,7 +24310,6 @@ <h4 title="Introspection">9.1.3. 自己検分</h4>
 <p>
 `ReadableStream$I %~stream は：
 </p>
-
 <ul>
 	<li>
 次を満たすとき，
@@ -24360,12 +24364,13 @@ <h4 title="Introspection">9.1.3. 自己検分</h4>
 これは、
 当の~streamは［
 一度でも読取られた／取消された
-］かどうかを指示する。
-これは、
-~web開発者が（間接的にも）~accessできる情報ではないので、
-この節に与える他の述語より，なおさら控えめに諮るのが最善である。
+］か否かを指示する。
+これは，~web開発者が（間接的にも）~accessできる情報ではないので、
+これに諮るのは
+— この節に与える他の述語より，なおさら —
+控えることが最善である。
 そのようなわけで、
-これに対し~platformの挙動が分岐することは，望ましくない。
+~platformの挙動が これに応じて分岐することは，望ましくない。
 ◎
 This indicates whether the stream has ever been read from or canceled. Even more so than other predicates in this section, it is best consulted sparingly, since this is not information web developers have access to even indirectly. As such, branching platform behavior on it is undesirable.
 </p>
@@ -24635,16 +24640,20 @@ <h4 title="Creation and manipulation">9.2.1. 作成と操作</h4>
 <hr>
 
 <p>
-以下に与える定義は、
-上の`設定しておく$WS~algoを介して初期化されたもの以外の `WritableStream$I ~instanceには，利用してはナラナイ。
+以下に与える定義は、［
+上の`設定しておく$WS~algoを介して初期化されたもの
+］以外の `WritableStream$I ~instanceには，利用してはナラナイ。
 ◎
 The following definitions must only be used on WritableStream instances initialized via the above set up algorithm:
 </p>
 
 <p class="algo">
-`WritableStream$I %~stream を所与の~JS値 %e で
+`WritableStream$I %~stream を
 `~errorにする@WS
-ときは
+ときは、
+所与の
+( ~JS値 %e )
+に対し
 ⇒
 ~NOABRUPT
 `WritableStreamDefaultControllerErrorIfNeeded$A( %~stream . `controller$wS, %e )
@@ -24681,12 +24690,12 @@ <h4 title="Creation and manipulation">9.2.1. 作成と操作</h4>
 通例的な用法は、
 `WritableStream$I を`設定しておいた$WS後に，
 その`通達$WSに［
-進行中な`下層~sink$への書込n演算があれば，それを中止する~algo
+進行中な`下層~sink$への書込n演算があるならば，それを中止する~algo
 ］を`追加-$aBすることである。
 それから，`下層~sink$が応答したなら、
 `書込n~algo$V の内側で，当の`通達$WSは`中止-済み$aBか否かを検査する
-— 中止-済みであるなら、
-当の通達の`中止-事由$aBで返された`~promiseを却下する$。
+— 中止-済みならば、
+当の通達の`中止-事由$aBで，返された`~promiseを却下する$。
 ◎
 The usual usage is, after setting up the WritableStream, add an algorithm to its signal, which aborts any ongoing write operation to the underlying sink. Then, inside the writeAlgorithm, once the underlying sink has responded, check if the signal is aborted, and reject the returned promise with the signal’s abort reason if so.
 </p>
@@ -25120,8 +25129,9 @@ <h4 title="Creation and manipulation">9.3.1. 作成と操作</h4>
 <hr>
 
 <p>
-以下に与える~algoは、
-上の`設定しておく$TS~algoを介して初期化されたもの以外の `TransformStream$I ~instanceには，利用してはナラナイ。
+以下に与える~algoは、［
+上の`設定しておく$TS~algoを介して初期化されたもの
+］以外の `TransformStream$I ~instanceには，利用してはナラナイ。
 それらは、
 通例的に［
 `形式変換~algo$V ／
@@ -25156,9 +25166,11 @@ <h4 title="Creation and manipulation">9.3.1. 作成と操作</h4>
 
 <p class="algo">
 `TransformStream$I %~stream を
-所与の~JS値 %e で
 `~errorにする@TS
-ときは
+ときは、
+所与の
+( ~JS値 %e )
+に対し
 ⇒
 ~NOABRUPT `TransformStreamDefaultControllerError$A( %~stream.`controller$tS, %e )
 ◎
@@ -25244,8 +25256,8 @@ <h4 title="Wrapping into a custom class">9.3.2. ~custom~classの中への包装-
 
 <p class="note">注記：
 基底 `TransformStream$I ~classが供するものを超える~APIは必要ない場合、
-それを包装する~classを作成する必要も無い。
-そのような包装体を要する~~誘因として最も共通的なのは，
+それを包装する~classを作成する必要もない。
+そのような包装体を要する最も共通的な~~誘因は、
 ~customな`構築子~手続き$が必要なときである
 — 当の概念的な形式変換~streamは、
 そのように構築されることは意味されないならば，
@@ -25279,7 +25291,7 @@ <h3 title="Other stream pairs">9.4. 他の~stream~pair</h3>
 `input^c, `output^c
 ］や［
 `readableStream^c, `writableStream^c
-］など）は利用するベキでない。
+］など）を利用するベキでない。
 また、
 ~methodその他の~prop以外の手段を利用して，当の~streamに~accessするベキでない。
 ◎
@@ -25292,12 +25304,13 @@ <h4 title="Duplex streams">9.4.1. 二重化~stream</h4>
 <p>
 最も共通的な［
 `readable^m, `writable^m
-］~pairは，
+］~pairは、
 `二重化~stream@
-（ `duplex stream^en ）であり、
-そこでは［
+（ `duplex stream^en ）である。
+そこでの［
 可読, 可書
-］~streamは，共有される同じ資源の 2 つの側を表現する
+］~streamは、
+共有される同じ資源の 2 つの側を表現する
 — ~socket, 接続, ~device, など。
 ◎
 The most common readable/writable pair is a duplex stream, where the readable and writable streams represent two sides of a single shared resource, such as a socket, connection, or device.
@@ -25311,7 +25324,7 @@ <h4 title="Duplex streams">9.4.1. 二重化~stream</h4>
 一方の側が他方の側に影響iしないような演算で，二重化~streamを “半ば~open” したままにすることは、
 イミを成すかもしれない。
 あるいは、
-それによる効果を他の側へ引継ぐのが最善かもしれない
+それによる効果を他の側へ引継ぐことが最善かもしれない
 — 例：［
 可読~側の `取消~algo＠#readablestream-set-up-cancelalgorithm$V が，可書~側を`~closeする$WSことになる
 ］よう指定するなど。
@@ -25330,16 +25343,17 @@ <h4 title="Duplex streams">9.4.1. 二重化~stream</h4>
 </p>
 
 <p>
-二重化~streamを非同期的に獲得する必要がある場合（例：接続を確立することを介して）、
-その作成を取扱う方法も，別の考慮としてある。
+二重化~streamを非同期的に獲得する必要がある場合
+（例：接続を確立することを介して）、
+別の考慮として，その作成を取扱う方法もある。
 ここで選好される~patternは、［
 実際の二重化~stream~objで充足するような~promise
 ］を返す~propを伴う，構築-可能な~classである。
 その二重化~stream~objは、
 非同期的にしか可用にならない情報（例：接続~data）も公開できる。
 この容器~classは、
 便利~API
-— 個々の側に限り~closeする代わりに接続を全体~closeする関数など —
+— 個々の側に限り~closeする代わりに接続~全体を~closeする関数など —
 を供せる。
 ◎
 Another consideration is how to handle the creation of duplex streams which need to be acquired asynchronously, e.g. via establishing a connection. The preferred pattern here is to have a constructible class with a promise-returning property that fulfills with the actual duplex stream object. That duplex stream object can also then expose any information that is only available asynchronously, e.g. connection data. The container class can then provide convenience APIs, such as a function to close the entire connection instead of only closing individual sides.
@@ -25360,8 +25374,8 @@ <h4 title="Duplex streams">9.4.1. 二重化~stream</h4>
 二重化~streamは、［
 `readable^m ／ `writable^m
 ］~propの契約を順守するので，
-`pipeThrough()$rs とともに利用できる。
-これは，常にイミを成すわけではないが、
+`pipeThrough()$rs と伴に利用できる。
+これは，常にイミを成すとは限らないが、
 下層の資源が何らかの類の形式変換nを~~実際に遂行している事例では，イミを成すこともある。
 ◎
 Because duplex streams obey the readable/writable property contract, they can be used with pipeThrough(). This doesn’t always make sense, but it could in cases where the underlying resource is in fact performing some sort of transformation.
@@ -25393,7 +25407,7 @@ <h4 title="Endpoint pairs">9.4.2. 端点~pair</h4>
 これらの事例では、［
 可読, 可書
 ］~streamは，より長い~pipelineの両端を表現する
-— ~web開発者の~codeが，その途中に`形式変換~stream$を挿入する意図nの下で。
+— ~web開発者の~codeが，その途中に`形式変換~stream$を挿入できるようにする意図nの下で。
 ◎
 Another type of readable/writable pair is an endpoint pair. In these cases the readable and writable streams represent the two ends of a longer pipeline, with the intention that web developer code insert transform streams into the middle of them.
 </p>
@@ -25634,8 +25648,10 @@ <h3 title="Piping">9.5. ~pipe法</h3>
 <p>
 `ReadableStream$I %~stream 用の
 `~proxyを作成する@RS
-ときは、次の手続きを遂行する
-— その結果は %~stream から~dataを~pullする新たな `ReadableStream$I ~objになり，それに伴い %~stream は即時に［
+ときは、
+次の手続きを遂行する
+— その結果は %~stream から~dataを~pullする新たな `ReadableStream$I ~objになり、
+それに伴い， %~stream は即時に［
 `~lockされて$RSいる
 ］~AND［
 `妨げられて$RSいる