[beacon] 編集（言い回し, 余計な訳注を除去, 対訳など

Author: triple-underscore

beacon-ja.html

@@ -244,7 +244,7 @@
 schedule::::スケジュール
 	他を阻まない:non-blocking
 	他を阻む:blocking
-集約-:coalesce:~
+合体-:coalesce:~
 競う:competeする:~
 	competing
 競合:contention:~
@@ -288,7 +288,6 @@
 害-:hurt:~
 offline::::オフライン
 	安全とされる:safelisted
-homescreen:
 mobile::::モバイル
 電力:energy:~
 	interactive
@@ -330,6 +329,7 @@
 	し易く:help
 	できる-:enable
 	しないようにする:prevent
+	至らす:lead
 
 	●未分類
 
@@ -344,14 +344,10 @@
 上限:limit:~
 	上限:limits
 
-	●指示語
-	種々の:various
-	等しい:equal
+	^en:homescreen
 	他の:different
-	起-:happen
 	量:amount
 	高い／高:high／higher
-	かもしれない:leads to
 	-:leave
 	-:parameter
 
@@ -490,11 +486,11 @@ <h2 title="Introduction">1. 序論</h2>
 送達~率を改善するために，
 各~beaconを即時に送達することを選んでいる
 — それらの送達を［
-集約する／遅延する
+合体する／遅延する
 ］代わりに。
 送達を遅延すると、
 ~beacon要請を成功裡に完了するための時間が足りなくなり，
-重要な~app~dataを喪失するかもしれないので。
+重要な~app~dataの喪失へ至らすこともある。
 ◎
 Developers opt for immediate delivery of each beacon, instead of coalescing and deferring their delivery because this provides improved delivery rates. Deferring delivery may mean that the beacon request may not have sufficient time to complete successfully, which leads to loss of important application data.
 </li>
@@ -545,7 +541,7 @@ <h2 title="Introduction">1. 序論</h2>
 </li>
 	<li>
 ~UAは、
-~mobile機器~上の電力~利用を最適化するために，~beacon要請を効率的に集約することもできる。
+~mobile機器~上の電力~利用を最適化するために，~beacon要請たちを効率的に合体することもできる。
 ◎
 Beacon requests may be efficiently coalesced by the user agent to optimize energy use on mobile devices.
 </li>
@@ -612,19 +608,18 @@ <h2 title="Introduction">1. 序論</h2>
 `PAGE-VISIBILITY-2$r に定義された
 【が，今や `HTML$r にて`定義される＠~HTMLinteraction#update-the-visibility-state$】
 `visibilitychange$et ~eventを利用する。
-この~eventは、
-~pageが［
+~mobile機器においては、
+この~eventが，~pageが［
 ~background状態へ遷移するとき
-（例：利用者が他の~appに切替えたとき, ~homescreenへ戻ったとき, 等々）／
-~unloadされているとき
-］に~mobile機器†上で発火されることが保証される，唯一の~eventである。
+（例：利用者が他の~appに切替えたとき, `homescreen^en へ戻ったとき, 等々）／
+~unloadされるとき
+］に発火されることが保証される唯一の~eventである。
 開発者は、
 `unload^et ~eventに依拠するのは避けるべきである
-— それは、
-~pageが~background状態にあるとき
+— それは，~pageが~background状態にあるとき
 （すなわち， `visibilityState$m は `hidden^l ）
-には発火されず，その処理nは~mobile~OS†により終了されるので。
-【†と記されているが、別に~mobile環境に限った話では無いであろう。】
+には発火されず、
+~mobile~OSにおいては，その処理nは終了されるので。
 ◎
 Above example uses visibilitychange event defined in [PAGE-VISIBILITY-2] to trigger delivery of session data. This event is the only event that is guaranteed to fire on mobile devices when the page transitions to background state (e.g. when user switches to a different application, goes to homescreen, etc), or is being unloaded. Developers should avoid relying on unload event because it will not fire whenever a page is in a background state (i.e. visibilityState equal to hidden) and the process is terminated by the mobile OS.
 </p>
@@ -1054,7 +1049,7 @@ <h2 title="Privacy and Security">4. ~privacyと~security</h2>
 ~UAは，［
 そのような要請を優先度化する
 ］ことも［
-それらを集約して~system資源の利用を最適化する
+それらを合体して~system資源の利用を最適化する
 ］こともできない。
 ◎
 The delivered data might contain potentially sensitive information, for example, data about a user's activity on a web page, to a server. While this can have privacy implications for the user, existing methods, such as scripted form-submit, image beacons, and XHR/fetch requests provide similar capabilities, but come with various and costly performance tradeoffs: the requests can be aborted by the user agent unless the developer blocks the user agent from processing other events (e.g. by invoking a synchronous request, or spinning in an empty loop), and the user agent is unable to prioritize and coalesce such requests to optimize use of system resources.