Plain strings section

[r12a]

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

[aphillips]

All strings are "machine-read strings" from the point of view the machines read them? We can consider renaming plain string (I'm not overjoyed by the term) and tightening definitions or making clear our intent---apparently we aren't doing that for you yet 😃.

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.

Argh. No, letter_spacing is not "natural language". It happens to be made of English word tokens, but it is a "program internal" string to CSS. CSS could have defined it as ar6Wt8=#z and it would have worked "just as well"---to the computer. The value was chosen because humans have to read and edit the CSS file. But letter_spacing is the same for French, Chinese, Arabic, or Bangla speakers--just like those speakers have to learn what for and int and let mean in a programming language. This is not English, this is Programmerese.

There are lots of times when natural language strings are not (immediately) consumed by human beings. We mean for the strings that will potentially be consumed by humans and which are "in a natural language" to have language (and direction). This includes messages for programmers/operators, who are, after all, humans--even if machines do occasionally peek at the data values.