Subject: IPP>MOD Specifiying locale for a response

From: Roger K Debry <[email-masked]>
Date: Tue, 18 Mar 1997 14:55:44 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

I know there have been some discussions on this but don't recall if there was
any resolution.  I was in Chelmsford MA on monday and spent an hour with Bob
Sproull from Sun who actually passed along this suggestion.  When some
responses (i.e. attribute values) can be passed back as text strings, Bob
suggested that we need some mechanism for the client to specify what language
the response should be returned in. Has that been discussed?  For example,
Printer location is a text string provided y an administrator. If users can
speak one of several languages, can the user say "send me the printer location
in language x"?

---

From: [email-masked] (Robert Herriot)
Date: Tue, 18 Mar 1997 15:32:59 -0800

We discussed this topic at a recent meeting. I think it was a model meeting.
We have talked about several strategies including the one you mention.
I agree with that strategy. It allows a client to specify a desired locale
and for a server to do its best to return text in that locale.  There are,
of course, lots of pitfalls in implementing all of this.

Bob Herriot

> From [email-masked] Tue Mar 18 11:59:05 1997

---

From: Patrick Powell <[email-masked]>
Date: Tue, 18 Mar 1997 18:08:51 -0800 (PST)

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

---

From: Roger K Debry <[email-masked]>
Date: Wed, 19 Mar 1997 09:24:37 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/19/97 07:19
AM ---------------------------

PERSONAL BIAS:

Have a set of languages supported,  default is 'English'
RKD> I agree that supporting a set of languages is the
RKD> best approach. However, I'd suggest that the
RKD> default language ought to be a configuration
RKD> option.

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...
RKD> In my previous note on this subject, I had suggested that
RKD> the client be able to ask for a response in a particular
RKD> language. For example:

RKD>   Get Attributes
RKD>    - locale for responses = french

RKD>   Response
RKD>    - printer location = some french text string

---

From: Harry Lewis <[email-masked]>
Date: Wed, 19 Mar 1997 09:59:10 -0500

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

        [email-masked]
        03/18/97 11:29 PM

>From Pat Powell...

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

PERSONAL BIAS:

What happened?

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.

Patrick Powell