From 0da547f3b5204181425f72b3fd64bb86b9d39af4 Mon Sep 17 00:00:00 2001
From: Fabian Steeg <steeg@hbz-nrw.de>
Date: Tue, 12 Sep 2023 14:39:28 +0200
Subject: [PATCH] Move language-related subsections into common i18n section
 (#125)

---
 draft/index.html | 57 +++++++++++++++++++++++++-----------------------
 1 file changed, 30 insertions(+), 27 deletions(-)

diff --git a/draft/index.html b/draft/index.html
index fbdba57..a643380 100644
--- a/draft/index.html
+++ b/draft/index.html
@@ -459,17 +459,6 @@ <h3>Cross-Origin Access</h3>
            enables older web-based clients to access the service from a different domain.
         </p>
       </section>
-      <section>
-        <h3>Language Selection</h3>
-        <p>
-           Following [[RFC9110]], services SHOULD use the <code>Accept-Language</code> header to let clients select the language in which user-facing text is returned.
-           They SHOULD use the <code>Content-Language</code> in their responses to expose the language each response is returned in.
-        </p>
-        <p>
-          Examples of user-facing text in service responses are: the name of the service and the name of property configuration fields in the manifest, the name and description of entities, types and properties,
-          the contents of the entity preview pages, and the documentation linked in the manifest.
-        </p>
-      </section>
       <section>
         <h3>Error Handling and Rate-limiting</h3>
         <p>
@@ -916,6 +905,36 @@ <h3>Data Extension Responses</h3>
         </p>
       </section>
     </section>
+    <section>
+      <h2>Internationalization Considerations</h2>
+      <section>
+        <h3>Language Selection</h3>
+        <p>
+           Following [[RFC9110]], services SHOULD use the <code>Accept-Language</code> header to let clients select the language in which user-facing text is returned.
+           They SHOULD use the <code>Content-Language</code> in their responses to expose the language each response is returned in.
+        </p>
+        <p>
+          Examples of user-facing text in service responses are: the name of the service and the name of property configuration fields in the manifest, the name and description of entities, types and properties,
+          the contents of the entity preview pages, and the documentation linked in the manifest.
+        </p>
+      </section>
+      <section>
+        <h3>Text-processing language</h3>
+
+        <p>All objects used in this protocol (entities, types, properties, queries, candidates, features, etc.) MAY declare an explicit <a href="https://www.w3.org/International/questions/qa-text-processing-vs-metadata">
+        text-processing languge</a> in a <code>lang</code> field. The <code>lang</code> value MUST be a single well-formed [[BCP 47]] language tag. This text-processing languge applies to the natural language fields of the object: <code>name</code>, <code>description</code>,
+        <code>query</code> (for <a>reconciliation queries</a>), <code>v</code> and <code>str</code> (for <a>property values</a>). Nested objects inherit the text-processing language of their parent, and can override it by setting their own <code>lang</code> value
+        (see example below). Client and service implementors SHOULD consider the text-processing languge to ensure correct processing of natural language content.</p>
+
+        <p>In the following example, we first set the text-processing language for a reconciliation query to <code>en</code>, which is inherited by the first property, and overridden in the second property with <code>zh-Hant</code>:</p>
+
+        <p>
+          <pre data-include="examples/reconciliation-query-batch/valid/text-processing-language.json" class="example json"></pre>
+        </p>
+
+        <p>If no explicit text-processing language is given, the metadata language (the language of the intended audience) provided first (see <a href="#service-definition">service definition</a>) is considered the default text-processing language.</p>
+      </section>
+    </section>
     <section>
       <h2>Accessibility Considerations</h2>
       <p>
@@ -945,22 +964,6 @@ <h3>Content semantics</h3>
           be modified by third-party tools to enhance accessibility.
         </p>
       </section>
-      <section>
-        <h3>Text-processing language</h3>
-
-        <p>All objects used in this protocol (entities, types, properties, queries, candidates, features, etc.) MAY declare an explicit <a href="https://www.w3.org/International/questions/qa-text-processing-vs-metadata">
-        text-processing languge</a> in a <code>lang</code> field. The <code>lang</code> value MUST be a single well-formed [[BCP 47]] language tag. This text-processing languge applies to the natural language fields of the object: <code>name</code>, <code>description</code>,
-        <code>query</code> (for <a>reconciliation queries</a>), <code>v</code> and <code>str</code> (for <a>property values</a>). Nested objects inherit the text-processing language of their parent, and can override it by setting their own <code>lang</code> value
-        (see example below). Client and service implementors SHOULD consider the text-processing languge to ensure correct processing of natural language content.</p>
-
-        <p>In the following example, we first set the text-processing language for a reconciliation query to <code>en</code>, which is inherited by the first property, and overridden in the second property with <code>zh-Hant</code>:</p>
-
-        <p>
-          <pre data-include="examples/reconciliation-query-batch/valid/text-processing-language.json" class="example json"></pre>
-        </p>
-
-        <p>If no explicit text-processing language is given, the metadata language (the language of the intended audience) provided first (see <a href="#service-definition">service definition</a>) is considered the default text-processing language.</p>
-      </section>
     </section>
     <section>
       <h2>Security Considerations</h2>