Plain strings section

Perhaps a better name for 'plain strings' would be 'machine-read strings'.

I don't see a clear statement that WGs don't need to worry about strings that won't be read by end users – which i think is what started this rewrite effort. The first sentence gets close, but doesn't punch the idea on the head.

This document is primarily concerned with natural language strings, that is, strings that contain human language content whose purpose is to be read or consumed by human beings.

I think that needs to say:

This document is primarily concerned with natural language strings whose purpose is to be read or consumed by human beings.

The definition of natural language string isn't confined to strings that will be read by humans. A CSS property name like letter_spacing is natural language. What we are focused on is the stuff that's consumed by human beings. I don't think we need to get people wondering about what is or isn't natural language (unless we define our usage of that term to be specifically stuff that's consumed by human beings).

We'll need to adapt some of the introduction text too. For example, i see:

The concepts in this document are applicable any time strings are used on the Web, either as part of a formalised data structure, but also where they simply originate from JavaScript scripting or any stored list of strings.

which we are contradicting in the plain strings section. Maybe that should say:

The concepts in this document are applicable any time strings aimed at consumption by humans are used on the Web, either as part of a formalised data structure, but also where they simply originate from JavaScript scripting or any stored list of strings.

At the bottom of the section we have (my bolding):

Specifications need to be careful to distinguish these "plain" string values from natural language text. Implementers are cautioned that in most instances these values should be wrapped with localizable display strings for presentation to the user (in cases where the values are enumerated in advance).

Which values? Again, we could take the opportunity to say the the other type of strings don't need to be wrapped (we already make the case for wrapping the 'natural language text' by writing a whole document about it ;-) ).

btw, langauge -> language

Start with the plain strings section and the introduction text discussed in this issue. Apply the requested terminology and wording changes, clarify which values need localization, and correct the language typo. Done means the document no longer contradicts itself about machine-read versus human-consumed strings.