In other words, the user who receives the message chooses the language
the message is displayed in by selecting a PC with IPP software which
has already been setup to support his language.
________________________________________________________________________
________________________________
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: Thursday, February 12, 1998 2:51 PM
> To: ipp@pwg.org
> Subject: RE: IPP> Notification Requirements
>
> Guys,
>
> 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