Tim Bray wrote:
On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
Martin describes a planet on which nroff formatting semantics are
considered to have current relevance, in which it's hard to look at 4
or 5 HTML documents simultaneously, in which people don't care which
characters are used to write their names, in which worrying about i18n
in protocols is a bad idea, in which people worry about viewing RFCs
on DSL routers but not mobile phones, in which printing HTML "just
doesn't work", in which it takes "fancy gadgets with lots of CPU
horsepower" to render HTML...
The IETF is not in the publishing business, and if you want to get
a scientific paper with pretty diagrams, math formulas, photos
in languages other than english and filled with fancy characters
from all over unicode, then you probably should go to either
one of the commercial publishers (a big one or a small one
like books-on-demand), but not to the IETF Editor.
Reflowing ASCII-formatted RFCs/I-Ds is really not very difficult,
if that is what some people need desperately for their SmartPhones.
Considering that NRoffEdit is fairly good at reflowing ASCII-formatted
I-Ds back into authoring .nroff source (which is still significantly
more readable and comprehensible than any XML and HTML btw.),
then providing such a tool for those gadget is probably two magnitudes
less work than implementing an HTML rendering engine. Making such
a tool accessible online at tools.ietf.org should not be that
difficult. It would even be possible to build magic into the
tools.ietf.org URL so that the format is chosen based on the
User-Agent present in the HTTP request header.
It is definitely completely unnecessary to change the authoring,
submission and archiving format of RFCs/I-Ds to accomplish this.
The ultimate disaster of I18N/L10N is what Microsoft did with Office97
when they localized the VBA keywords (one of the reasons why some
companies stopped using localized MS Office versions back then).
When I started using and programming computers, none of them had
localization (everything in english). But when learning terminology
for formerly unknown stuff then one gets accustomed to the new
terminology being drawn from a different language rather than
mocked up from ones own if there is at least some familarity
with that foreign language.
Trouble started when I was first faced with "localized" versions of
operating systems and application (from Microsoft and IBM), because
it was almost incomprehensible to me. It felt strange to read words
in a documentation that sound like they're from your own language
but don't make any sense to you such as "serielles Zeigeinstrument" (IBM).
If air treffic controllers would start using only local/national terminology
when talking to pilots, then the number of accidents would increase
significantly.
I see it as a benefit not having to learn the local language of a
country before being able to go there and use a phone, drive a car,
go shopping, use some multimedia equipemnt or even a computer.
It's less of a problem if you can easily switch the technology
between localizations while using it--which, fortunately, is becoming
more an more common. The important part is, that internally, the
technology should use a single common format, the localization should
only affect the output, not the processing. The are OSes that use
UTC internally and localtime() in a sane fashion, and unfortunately
there is one, that doesn't -- causing lots of interop pain, with others
and with other incarnations of itself and even with itself.
I congratulate SAP for their bold vision in extending their operations
beyond the bounds of planet Earth.
In the IETF people participate as indiviuals, unless explicitly
state otherwise, and despite many of the participants having
corporate sponsors paying for some or all of the expenses and
contributions.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf