Hi Bob,
You just said the spec 'leaves phrasing ... of messages
to each vendor'. But the spec REQUIRES various content
for each message (such as 'printer-name').
I believe that some guidance (at least) should be in
the spec about how, in any language, that content is
provided.
Since 'printer-name' is NOT French, how is the fact
that the content includes a value for 'printer-name'
known to the end user? If each vendor translates not
only free-form text (like status messages) but
attribute names and attribute keyword values
independently (and often product by product,
sadly), then where's the benefit to the end user?
Three different printers emitting human-readable
email notifications in French that are fully product
unique?
There are approaches to minimize this problem, like a
structured format for layout of the 'human-readable'
phrases (which might always include the English
original name for the attribute in parentheses, e.g.).
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
Sent: Monday, August 21, 2000 2:17 PM
To: McDonald, Ira; 'jkm at underscore.com'
Cc: 'ned.freed at innosoft.com'; ipp at pwg.org
Subject: RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
The IPPNotification I-Ds will now go the IESG)]
Rather than saying that 'mailto' dodges the I18N issue, could you say what
you think should be added to the spec?
The current 'mailto' spec presumes knowledge of email. It specifically
leaves the phrasing (and translation) of messages to each vendor. So the
translation of 'job-id' is not an issue that the spec need address. However,
the spec does contain examples in both English and Danish.
I did have a French example, but removed it because of the difficulty of
displaying non-ascii characters in an RFC. I could have used
quoted-printable encoding, but then the French would be hard to read. Other
encoding would have been even harder to read.
Bob Herriot
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> Sent: Friday, August 18, 2000 7:16 PM
> To: 'jkm at underscore.com'; McDonald, Ira
> Cc: 'ned.freed at innosoft.com'; ipp at pwg.org> Subject: RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> The IPPNotification I-Ds will now go the IESG)]
>>> Hi Jay,
>> The IPP 'mailto:' notification method recommends
> suitable content for the human-readable notification,
> while gracefully dodging the issues of I18n for
> tagging of that content.
>> How does a user know that the next few characters
> are 'job-id' rather than something else?
> Are there 'labels' that are translations of the intent
> (if not the name) of IPP attributes in the notification?
>> Is the notification an actually linguistically correct
> _whole_sentence_ in the target notification language?
> How can we have a standardized email notification
> that doesn't address the human usability of the
> content?
>> Cheers,
> - Ira McDonald
>> -----Original Message-----
> From: Jay Martin [mailto:jkm at underscore.com]
> Sent: Friday, August 18, 2000 6:51 PM
> To: McDonald, Ira
> Cc: 'ned.freed at innosoft.com'; ipp at pwg.org> Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> TheIPPNotification I-Ds will now go the IESG)]
>>> Ira,
>> No one ever, *ever* said I18N in mail messages wasn't difficult.
> Don't know how you came to that conclusion.
>> In fact, with the exception of Tom Hastings (big surprise),
> there hasn't been a word said on this thread by anyone
> else about I18N in email notifications, except for your
> comments and the interesting side comment by Ned.
>> ...jay
>>> "McDonald, Ira" wrote:
> >
> > Hi Ned,
> >
> > Thanks - you're the only person who has reinforced my
> > periodic comments that the I18N for the stuff in the
> > 'simple text' email notifications is a nice juicy
> > problem - since IPP and most (or all?) shipping IPP
> > Printer implementations define support for multiple
> > human languages and charsets.
> >
> > And the fact that a client can ask for a notification
> > in some other charset than UTF-8 further complicates
> > I18N, because the obvious starting point (message
> > catalogs in UTF-8) leads to smashed characters in
> > many local charsets.
> >
> > I think the IPP 'mailto:' notification method should
> > be a good deal more complete on this I18N topic.
> >
> > Cheers,
> > - Ira McDonald, consulting architect at Xerox and Sharp
> > High North Inc
> >
> > -----Original Message-----
> > From: ned.freed at innosoft.com [mailto:ned.freed at innosoft.com]
> > Sent: Friday, August 18, 2000 8:21 AM
> > To: pmoore at peerless.com> > Cc: David_Kellerman at nls.com; kugler at us.ibm.com; ipp at pwg.org> > Subject: Re: IPP>NOT mailto feature from IETF meeting (RE:
> IPP> ADM -
> > TheIPPNotification I-Ds will now go the IESG)]
> >
> > <...snip...>
> >
> > Frankly, the bigger problem with this stuff is i18n support
> for the text.
> > But that's a different topic.
> >
> > IMO the supposed difference between simple text and a
> structured report is
> a
> > chimera. Email support in general is another matter, of course.
> >
> > Ned
>