Pat, again, I think it so greatly depends on where you expect these
translations to take place. If they must "emanate" from the printer itself,
then I vote for numbers. We have to remember, the primary purpose of a printer
is to print. We want robust management also, but not at the expense of storing
translations of long, human readable strings, for events and error conditions.
A pragmatic approach, which I believe is common today, is to translate terse
"OpPanel"
messages. These translations may also be used in remote management. These are
usually brief strings and a limited set. More lengthy and/or detailed
diagnostic responses are typically "coded" or English only.
Of course, larger, more expensive printers have more horsepower for both
printing and management, but the scheme you are searching for needs to cross
all (managed) products.
Respectfully, Harry Lewis - IBM Printing Systems
---- Forwarded by Harry Lewis/Boulder/IBM on 03/19/97 07:46 AM ---
ipp-owner@pwg.org
03/18/97 11:29 PM
I have been discussing implementation of locale and internationalization
of software with several groups, and <Throw hands up in despair> if you thought
PRINTING was a matter of 'open and vigorous exchange of ideas' then the
locale and internationalization folks are having a nuclear war.
Well... exchange of mortar and small arms fire at the very least.
There appear to be the following opinions.
1. All messages should be 'numerical values' and everybody should
buy the code book from the manufacturer. (Hmmm... HP? printer
status? IBM? Sys001? Hmm???)
2. All messages should be a 'numericals value' AND a 'cannonical string'
in a stanard language. This appears to be Technical English, a horrible
invention
of the computer era. The reader can then use a 'code book' to translate
to his local language. Or they can learn English. (Biased? Moi? C'est
impossible...)
3. The system you are querying supports a set of languages, and you can request
that messages are translated/provided in a language from the set. In
addition,
you add a numerical value indicating the message number which you can then
look up in a code book.
Everybody agrees that numbers work great for 'fixed error messages' but bomb
when you want to report 'error in input on line 45' and then they start flaming
each other about various schemes to support language independent message
formats...
(By the way, Microsoft has a very nice scheme for message formatting that
somebody who used it spoke highly off.)
I am not an expert on this, but the experts seem to indicate that there is not
a reasonable level of agreement on providing translation of messages whose
content is not fixed.
PERSONAL BIAS:
Have a set of languages supported, default is 'English'
I.e. - the following exchange might take place:
WhatLanguagues do you support???
Answer: 101 en fr sp
SendMessagesLocal= (fr en sp)
Answer: 102 <fr> oui. en francais
What happened?
Answer: 103 <en> I dunno. This error is very strange
Answer: 103 <fr> Je ne fait pas une faut! C'est les autres!
* note the above is my small nieces contribution...
It would appear that the answer should also contain an indication of the
language so that the receiver can make a determination of what to do if the
response is in an inappropriate language.
Just throwing gasoline onto the fire.
Patrick Powell