Create guidelines for name-like fields

Addresses i18n-actions#39

- Add new section "Working with Non-Localizable and Localizable Data
  Values"
- Add three new requirements.
- Add explanatory text.

index.html

@@ -3420,6 +3420,43 @@ <h3>Defining identifiers</h3>
 
 </section>
 
+<section id="" class="subtopic">
+<h3>Working with Non-Localizable and Localizable Data Values</h3>
+
+   <div class="req" id="">
+   <p class="advisement">Specifications that define non-localizable data values intended to be machine-readable should choose values that are not readily confused with natural language text.</p>
+   </div>
+
+   <p>Many protocols, document formats, or data structures define enumerated values for internal use. These values are never visible to humans directly. Sometimes it is helpful if these values are given descriptive names (often in English) to aid users working with the specification, protocol, or API or who might need to debug a given document or interaction. When a specification assigns these values, the names should appear to be "code-like" so that users do not assume that the value can be displayed as if it were natural language text.</p>
+
+   <p>A common best practice is to use SNAKE_CASE, naming the field in English, using ASCII letters and digits, all in uppercase, with words separated by underscores (<span class="codepoint"><bdi lang="en">_</bdi><code class="uname">U+005F LOW LINE</code></span>).</p>
+
+   <aside class="example" title="Example of code internal values">
+	   <p>For example, a specification might define a field <code>result</code> which can include the status of the transaction.</p>
+	   <p>The best practice would be to provide return values for <code>result</code> that are code-like. For example:
+	      <ul>
+			  <li><code>SUCCESS</code></li>
+			  <li><code>FAILED</code></li>
+			  <li><code>NOT_AUTHENTICATED</code></li>
+	      </ul>
+	   </p>
+   </aside>
+
+   <div class="req" id="">
+   <p class="advisement">Fields intended for consumption by humans must always be treated as <a>natural language</a> string values. It must be possible to find the language and base direction metadata for every such field.</p>
+   </div>
+
+   <p>Fields that contain human-readable strings, particularly those of a descriptive nature, must be assumed to be natural language strings. This is true even if the user viewing the string is expected to be a software developer. It must be possible to determine the language tag and base paragraph direction for each such field in a document or data structure.</p>
+
+   <p>Common names for fields of this type include <code>name</code>, <code>description</code>, <code>title</code>, <code>message</code>, or occassionally <code>value</code>. One test for this is if, as a specification author or user, you are uncomfortable making the content of the field <kbd>SNAKE_CASE_SHOUTED</kbd>, the field might be better considered as natural language text.</p>
+
+   <div class="req" id="">
+   <p class="advisement">Fields intended for consumption by humans should be localizable.</p>
+   </div>
+
+   <p>This can take various forms. For example, a specification or protocol might allow for language negotiation and only return the best matching localized strings. Or a given resource might contain multiple languages that the <a>consumer</a> can choose between.</p>
+
+</section>
 
 <section id="markup_plaintext" class="subtopic">
 <h3>Working with plain text</h3>