Subject: RE: PROPOSAL: CAP Error codes definition and handling

From: Doug Royer <[email-masked]>
Date: Tue, 18 May 1999 17:05:53 -0700 (PDT)

> From: Frank Dawson/CAM/Lotus <[email-masked]>
> Date: Tue, 18 May 1999 23:53:41 GMT
> 
> >> It seems weird that we would be asking the CS to "translate" text
> strings.
> 
> >I Never said that.
> 
> But you implied that the CUA could "ask" the CS for a particular
> translation. That means that it must select the requested "translation" of
> its standard response. An apparent translation, to me ;-)

I don't know how others do this, here is a standard Unix way to
send localized messages.

We compile in our source code calls to catgets(catfd,msg#, default)
function call. That allows us to specify a message number and default
message.

Here is how I see a multi-local CS working:

	CUA	->	CS		My preferred lang

  When a text message needs to be sent to the CUA from the CS
  
	catfd = ...open "lang"-specific msg file if not already opened.
	
	~send~ catgets(catfd, message-number, "this is the default message")
	
I am sure that other OS's to the same kind of thing.

So when our product is released, we have our known (compiled in) messages
translated and shipped with the product. In order for our servers
to know which message file to open, the CUA MUST inform the CS.

Without something like this, there is NO WAY a CS can guess at
the language understood by the calendar user.

I still would prefer that NO text ever be sent at the PROTOCOL level.
	
> But I definitely concur that we are not asking the CS to "automagically"
> translate textual responses.
> 
> Hence, why don't we just do as Lisa has suggested...provide a standard
> US-EN text string in the CAP spec. The CS will always emit this, if it
> emits an optional text string in addition to the hierarchical status code,
> at all. And allow the CUA to use any of its nationalized strings to display
> to the user, if it wants.

If its a predefined string - never send it.

If it for diagnostics only - make the text part optional.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: David Madeo <[email-masked]>
Date: Tue, 18 May 1999 21:06:41 -0400

> If it for diagnostics only - make the text part optional.

To Clarify: Allow the CUA to use any of it's nationalized strings to the user,
as long as it's picking the strings based on the status code and not the
optional text.  The official optional US-EN text string is merely to aid a human
reading a protocol trace.

One thought though: Implementations should be able to turn this "diagnostic
text" on and off, but they need to be able to produce the official optional
US-EN text as well as parse it.  Otherwise, it's not worth any of the time we've
been spending on this.  If some support person in the future is trying to figure
out why A and B are not playing nice with each other and only one product can
print out the human friendly text, then they will still have to look up the
error codes from the other product.   Small footprints beware.

Personally, I'm in favor of short predefined official optional US-EN text
strings.  Let's put this one to bed too.

dmadeo