Ron Bergman
Dataproducts Corp.
On Thu, 12 Feb 1998, Gordon, Charles wrote:
> I don't think restricting the set of notification messages is too much
> of a limitation. After all, all of the messages are generated by
> software. Therefore, they will be canned messages anyway.
>
> 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
>