IPP>MOD Specifiying locale for a response

IPP>MOD Specifiying locale for a response

IPP>MOD Specifiying locale for a response

Harry Lewis harryl at us.ibm.com
Wed Mar 19 09:59:10 EST 1997


Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems


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 at 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



More information about the Ipp mailing list