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 at wal.osicom.com]
Sent: Thursday, February 12, 1998 7:36 AM
To: 'Turner, Randy'; ipp at 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 at osicom.comhttp://www.digprod.com
> -----Original Message-----
> From: Turner, Randy [SMTP:rturner at sharplabs.com]
> Sent: Thursday, February 12, 1998 9:45 AM
> To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry;
ipp at 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 at wal.osicom.com]
> Sent: Thursday, February 12, 1998 6:37 AM
> To: 'Carl-Uno Manros'; Roger K Debry; ipp at 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 at osicom.com
> http://www.digprod.com
>
> > -----Original Message-----
> > From: Carl-Uno Manros [SMTP:cmanros at cp10.es.xerox.com]
> > Sent: Wednesday, February 11, 1998 7:32 PM
> > To: Roger K Debry; ipp at 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 at 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 at cp10.es.xerox.com