Keith Moore writes:
I suggest that you not explicitly include programming languages
in the set of languages to be covered by content-language.
One danger is that it starts to conflict with content-type.
One possibility is to register a general content-type
Text/Source-Code for all uses of text written primarily to be
used by programs. What programming language or notation is used
would then be indicated in a Content-Language: header. To
indicate the human language of program messages or comments in
the source code also a language-tag for that language can be
given in the Content-Language: header. The content of the
Content-Type: header shows that this language is subordinate in
this case.
Another possibility is to register a new subtype of
content-type Text for every programming language or notation.
The Content-Language: header would then be usable only to
indicate the human language of strings or comments.
One disadvantage of the second solution is that programming
languages will have to be registered both as subtypes of Text
and as langauge-tags, otherwise it will not be possible to
indicate which programming language is used in a message or
body-part when program fragments are embedded in ordinary text.
If both human languages and computer languages are possible to
register, it might be advantageous to have different principal
tags for them, "ianahl" and "ianapl" perhaps.
Another is that there are sometimes different versions of a program --
one for English speakers, another for French, etc -- but all written
in C.
Then both "ianapl-c" and "en" or "fr" could be included in the
header. And strings may be in one human language and comments in
another, by the way.
We've run into a similar conflict with the netlib mathematical software
repository (consisting mostly of FORTRAN and C programs and subprograms) --
which also happens to include more traditional literature like research papers
and documentation. Our experience with the use of the "language" field in our
bibliographic entry to describe both programming languages and human
languages, has been awkward at best. For example: when searching, it doesn't
work to restrict queries to items using "C" as a language, because that would
exclude the documentation (written in English).
Language-tags can be used in other protocols, like
IAFA-templates or URCs for bibliographic information. Those
protocols can of course have separate fields for programming
language, documentation language, dialog language etc.
/Olle