Defining a set of messages to support will not prevent us from adding
new ones later. If an IPP client receives a new message type which it
doesn't recognize, it can either display the English version of it
(supplied by the IPP server), or simply tell the user that it received a
message it doesn't understand. New messages won't be supported by old
software, but this just gives users an incentive to buy new software
from us :-).
________________________________________________________________________
________________________________
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 11:44 AM
> To: 'Gordon, Charles'
> Cc: 'ipp@pwg.org'
> Subject: RE: IPP> Notification Requirements
>
>
> I thought this was what you meant. I just wanted to make it clear that
> client-localization requires defining a strict set of possible
> messages,
> with an associated token or code so that the client knows how to look
> up
> the localized version of this message in a localization dictionary (or
> catalog, or whatever). I wonder if absolutely restricting the set of
> messages that can be sent from server to client is too constraining?
>
> Randy
>
>
> -----Original Message-----
> From: Gordon, Charles [SMTP:CGordon@wal.osicom.com]
> Sent: Thursday, February 12, 1998 7:36 AM
> To: 'Turner, Randy'; ipp@pwg.org
> Subject: RE: IPP> Notification Requirements
>
> 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