I think you are making it too easy.
There are a number of places that are multi-lingual and there is not
necessarily ONE localiced language (Florida, California, Canada and
Switzerland are concrete examples, not to mention the UN offices in New
York or the EU offices i Brussels).
So even if we encode all messages in some language independent way, we
might still need to indicate in the messages in which language they should
be displayed to a particular user.
Carl-Uno
At 07:36 AM 2/12/98 PST, Gordon, Charles wrote:
>The simplest way would be to restrict IPP to a specific set of
>notification messages. The localized version of the IPP client would
>have these messages translated into the local language. When the IPP
>client reads the message from the IPP server, it would determine which
>notification event occurred and produce the localized version version of
>the message for it.
>
>For a simple example, suppose IPP supports the following notification
>messages.
>
>1. Print job %job-name% which was sent to you by %sender% was printed
>on printer %printer% on %date% %time%.
>2. Print job %job-name% which was sent to you by %sender% was aborted
>on %date% %time% because of errors on printer %printer%.
>3. Print job %job-name% which you sent to %receipient% has been printed
>on printer %printer% on %date% %time%.
>
>and so on....
>
>The idea here is that we define a message for each type of event which
>IPP will send notification of. The strings can include tokens like
>%job-name% which will be replaced by the client with strings which
>represent the actual values assigned to them.
>
>When the IPP server sends a message, it sends it in a format which the
>IPP client can recognize. For example, suppose the IPP server sends a
>notification to a receipient that a job has been printed (message 1
>above). The IPP server formats the message so that client software can
>recognize that it is a notification that event 1 happenned, and sends
>values for the %job-name%, %sender%, and other tokens. The IPP client
>retrieves the localized text for notification event 1 and inserts the
>values for the tokens into the message. The localized message can now
>be displayed to the user.
>
>Well written Windows programs are designed so that they can be easily
>localized. All text is stored in a seperate file which can be localized
>without changing the code. If I write a Windows program which uses
>English, I can send the 'resource' file (which contains all my English
>text strings) to some translation house and have them provide localized
>versions for all the languages I want to support. Localized IPP clients
>can be create in this fashion. I would assume that other operating
>systems also support localization one way or another.
>
>I know the above example is rather simple, but I think it shows how
>localization could be done.
>
>________________________________________________________________________
>________________________________
>Charles Gordon
>Osicom Technologies, Inc.
>cgordon@osicom.com
>http://www.digprod.com
>
>> -----Original Message-----
>> From: Turner, Randy [SMTP:rturner@sharplabs.com]
>> Sent: Thursday, February 12, 1998 9:45 AM
>> To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org
>> Subject: RE: IPP> Notification Requirements
>>
>>
>> Can you elaborate a little on the exact method for how a client would
>> apply localization to a server-generated message?
>>
>> Randy
>>
>>
>> -----Original Message-----
>> From: Gordon, Charles [SMTP:CGordon@wal.osicom.com]
>> Sent: Thursday, February 12, 1998 6:37 AM
>> To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org
>> Subject: RE: IPP> Notification Requirements
>>
>> If localization of messages is a requirement (and it should be),
>> I would
>> suggest that messages be localized by software on the receiver's
>> PC.
>> This would work as follows:
>>
>> 1. IPP server sends message (by whatever means) to an IPP
>> client on the
>> remote user's PC. This message would be formatted to be easily
>> machine
>> readable.
>> 2. Software on remote user's PC retrieves the message and
>> localizes it.
>> 3. Localized message it displayed to user.
>>
>> The advantage in this approach is that the IPP server does not
>> need to
>> support different languages and character sets. Instead, IPP
>> client
>> software does this. Since the client software is on the remote
>> user's
>> PC, the user would, presumably, have installed a localized
>> version of
>> the software, and the PC will be setup with the correct
>> character set.
>>
>> It will probably be desirable to make the original message sent
>> from the
>> IPP server to the client human readable as well as machine
>> readable.
>> This would allow users to read the message even if they don't
>> have IPP
>> client software. This could be done by either generating the
>> message as
>> English text (the defacto International standard language)
>> formatted to
>> make parsing by software easy, or by generating a two part
>> message where
>> one part is text and the other part is machine readable.
>>
>> If email is used for notification messages (and it does seem
>> like a good
>> choice), then the message from the IPP server could be sent to a
>> special
>> mailbox setup at the remote site. The IPP client software could
>> be a
>> specialized mail client which decodes the messages, localizes
>> them, and
>> displays them to the user. If the user does not have IPP client
>> software, he would still be able to access the messages with a
>> standard
>> mail client and read them in English.
>>
>> That's just a suggestion for how I would approach the problem.
>> The main
>> point I am trying to make (which I am sure someone has already
>> made) is
>> that the IPP server should not have to localize notification
>> messages.
>> Localization should be done on the client side.
>>
>>
>> ______________________________________________________________________
>> __
>> ________________________________
>> Charles Gordon
>> Osicom Technologies, Inc.
>> cgordon@osicom.com
>> http://www.digprod.com
>>
>> > -----Original Message-----
>> > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
>> > Sent: Wednesday, February 11, 1998 7:32 PM
>> > To: Roger K Debry; ipp@pwg.org
>> > Subject: Re: IPP> Notification Requirements
>> >
>> > Roger,
>> >
>> > One requirement, which we have discussed earlier, but seems to
>> have
>> > been
>> > forgotten lately, is the ability to request the human readable
>> > notifications in different langauges.
>> >
>> > E.g. I want to send a document for review to our offices in
>> Japan and
>> > want
>> > to have any notifications to my collegue in Tokyo in Japanese,
>> while I
>> > want
>> > to have my own notifications in Swedish :-)
>> >
>> > Can we create a scenario for this?
>> >
>> > Carl-Uno
>> >
>> >
>> > At 08:22 AM 2/10/98 PST, Roger K Debry wrote:
>> > >I have taken a pass at writing down a set of notification
>> > requirements.
>> > >They are in the PDF file attached to this note. I'd be glad
>> to take
>> > >comments and suggestions and turn this into a formal
>> requirements
>> > >document, if you all feel that this would be useful.
>> > >
>> > >
>> > >
>> > >
>> > >Roger K deBry
>> > >Senior Technical Staff Member
>> > >Architecture and Technology
>> > >IBM Printing Systems
>> > >email: rdebry@us.ibm.com
>> > >phone: 1-303-924-4080
>> > >
>> > >Attachment Converted:
>> > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf"
>> > >
>> > Carl-Uno Manros
>> > Principal Engineer - Advanced Printing Standards - Xerox
>> Corporation
>> > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
>> > Phone +1-310-333 8273, Fax +1-310-333 5514
>> > Email: manros@cp10.es.xerox.com
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com