CLDR-00000 Automated Build of Pages

ldml/tr35-keyboards.html

@@ -1647,7 +1647,7 @@
 <span class="hljs-tag">&lt;/<span class="hljs-name">keys</span>&gt;</span>
 …
 <span class="hljs-tag">&lt;<span class="hljs-name">transforms</span>&gt;</span>
-    <span class="hljs-comment">&lt;!-- this wouldn't match the key X output because of the marker --&gt;</span>
+    <span class="hljs-comment">&lt;!-- this wouldn't match the key caret output because of the marker --&gt;</span>
     <span class="hljs-tag">&lt;<span class="hljs-name">transform</span> <span class="hljs-attr">from</span>=<span class="hljs-string">"^e"</span> <span class="hljs-attr">output</span>=<span class="hljs-string">"ê"</span>/&gt;</span>
 <span class="hljs-tag">&lt;/<span class="hljs-name">transforms</span>&gt;</span>
 </code></pre><p>Pressing <code>caret</code> <code>e</code> will result in <code>^e</code> (with an invisible <em>no_transform</em> marker — note that any name could be used). The <code>^e</code> won’t have the transform applied, at least while the marker’s context remains valid.</p><p>Another strategy might be to use a marker to indicate where transforms are desired, instead of where they aren't desired.</p><pre><code class="language-xml"><span class="hljs-tag">&lt;<span class="hljs-name">keys</span>&gt;</span>
@@ -1660,7 +1660,7 @@
     <span class="hljs-comment">&lt;!-- Won't match ^e without marker. --&gt;</span>
     <span class="hljs-tag">&lt;<span class="hljs-name">transform</span> <span class="hljs-attr">from</span>=<span class="hljs-string">"^\m{transform}e"</span> <span class="hljs-attr">output</span>=<span class="hljs-string">"ê"</span>/&gt;</span>
 <span class="hljs-tag">&lt;/<span class="hljs-name">transforms</span>&gt;</span>
-</code></pre><p>In this way, only the <code>X</code>, <code>e</code> keys will produce <code>^e</code> with a <em>transform</em> marker (again, any name could be used) which will cause the transform to be applied. One benefit is that clicking or using the arrow key to navigate existing text with <code>^e</code> will never be affected by the transform, because the marker is not or no longer present.</p><p><strong>Effect of markers on final text</strong></p><p>All markers must be removed before text is returned to the application from the input context.
+</code></pre><p>In this way, only the <code>X</code>, <code>e</code> keys will produce <code>^e</code> with a <em>transform</em> marker (again, any name could be used) which will cause the transform to be applied. One benefit is that navigating to an existing <code>^</code> in a document and adding an <code>e</code> will result in <code>^e</code>, and this output will not be affected by the transform, because there will be no marker present there (remember that markers are not stored with the document but only recorded in memory temporarily during text input).</p><p><strong>Effect of markers on final text</strong></p><p>All markers must be removed before text is returned to the application from the input context.
 If the input context changes, such as if the cursor or mouse moves the insertion point somewhere else, all markers in the input context are removed.</p><p><strong>Implementation Notes</strong></p><p>Ideally, markers are implemented entirely out-of-band from the normal text stream. However, implementations <em>may</em> choose to map each marker to a <a href="https://www.unicode.org/glossary/#private_use_character">Unicode private-use character</a> for use only within the implementation’s processing and temporary storage in the input context.</p><p>For example, the first marker encountered could be represented as U+E000, the second by U+E001 and so on.  If a regex processing engine were used, then those PUA characters could be processed through the existing regex processing engine.  <code>[^\u{E000}-\u{E009}]</code> could be used as an expression to match a character that is not a marker, and <code>[Ee]\u{E000}</code> could match <code>E</code> or <code>e</code> followed by the first marker.</p><p>Such implementations must take care to remove all such markers (see prior section) from the resultant text. As well, implementations must take care to avoid conflicts if applications themselves are using PUA characters, such as is often done with not-yet-encoded scripts or characters.</p><hr><h3 id="Element_transformGroup"><a name="element-transformgroup" href="#Element_transformGroup">Element: transformGroup</a></h3><blockquote>
 <small>
 

ldml/tr35-keyboards.md

@@ -1732,7 +1732,7 @@ One strategy would be to use a marker, which won’t be visible in the output, b
 </keys>
 …
 <transforms>
-    <!-- this wouldn't match the key X output because of the marker -->
+    <!-- this wouldn't match the key caret output because of the marker -->
     <transform from="^e" output="ê"/>
 </transforms>
 ```
@@ -1754,7 +1754,7 @@ Another strategy might be to use a marker to indicate where transforms are desir
 </transforms>
 ```
 
-In this way, only the `X`, `e` keys will produce `^e` with a _transform_ marker (again, any name could be used) which will cause the transform to be applied. One benefit is that clicking or using the arrow key to navigate existing text with `^e` will never be affected by the transform, because the marker is not or no longer present.
+In this way, only the `X`, `e` keys will produce `^e` with a _transform_ marker (again, any name could be used) which will cause the transform to be applied. One benefit is that navigating to an existing `^` in a document and adding an `e` will result in `^e`, and this output will not be affected by the transform, because there will be no marker present there (remember that markers are not stored with the document but only recorded in memory temporarily during text input).
 
 **Effect of markers on final text**