Some comments on User Scenarios

I was just reading through the document and had some comments:

<citation>
Service "A" is defined on Provider "A". A fault is generated during invocation that returns a faultReason that includes locale affected values.

  a.. "The date provided, 12 November 2201, was too late."

  b.. "The argument 12345.678 was too large."

  c.. "The argument 12345,678- was too small."

How does the provider perform the substitutions?

</citation>

I'll include a bit of a document here that we could discuss:

In general, error messages should be resolved as close to the user as possible. Why do we make that claim? An error might be generated in the bowels of a server module somewhere, where the end-user's language or other information about the user is not known. If the error text is composed at that point, it may be very difficult to eventually display it to the user in the user's language.

In the globalization architecture, the error is recorded at the error site with as much information as possible, in as language-neutral a format as possible. The actual production of the error text is delayed until enough information about the user (such as the user's language) is known, so that a correct translated error string can be looked up. For example, the error might record an error key, a date, and a quantity. At the point in the error processing where the user's language is known, the error key is used to look up localized error text. The variable information is inserted in the text in the appropriate place (this place must be localizable!) and is eventually presented to the user.

Example: In Java this could look like:

// at the error site

throw MyProgramException("Missing Records", new Date(), recordCount);

// at the UI

...catch (MyProgramException exception) {

    String message = userResources.getString(exception.getMessage());

    String resolvedMessage = MessageFormat.format(message, exception.getArguments());

    visibleErrorField.setText(resolvedMessage);

}

The resolution of error messages need not take place on the client side. For example, a Web server can have the user's locale information at a high level and also have locale-specific error text. The resolution can take place in the server, resulting in the correct text in the Web page served to the end user. This also requires there to be some client-state information that the server can access, through an EJB or other mechanism.

An advantage of this approach is that the very same error message can be formatted for different users in their own languages. It is in line with the principle of exchanging language-neutral data where possible, and formatting for the user as high in the process as feasible.

This has a bearing on the notion of locale that has been discussed on this list, as well.

Mark
________
mark.davis@jtcsv.com
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799
 
----- Original Message ----- 
From: "Tex Texin" <tex@i18nguy.com>
To: "Web Services" <public-i18n-ws@w3.org>
Sent: Tuesday, January 28, 2003 11:45
Subject: use case requiring failure if locale is not available


> 
> Currently, if a requester specifies a locale and the service does not
> know of or has no provision for that particular locale, you get some
> default behaviors. The behaviors may be completely unrelated or
> inappropriate for the requested locale.
> 
> However, if Web Services are to be used in an automated fashion, this
> may be unacceptable.
> 
> For example, if a business prepares to produce a large run of reports
> overnight, and the locale of the user for each report is specified,
> there is no way of knowing which reports have been satisfactorily
> produced and can be given to the user and which reports will not meet
> the user's needs (wrong date formats, language etc.) and should not be
> given to the user. (I am assuming the user is a paying customer of the
> business.)
> 
> 
> It would be better in this situation for a web service to return an
> error indicating that the locale is unknown or not provided for and to
> have the service request error. This would allow the business to choose
> suitable alternatives in behalf of the users with failed requests and
> rerun the reports to get acceptable ones.
> 
> This is of course an argument for an upfront negotiation of locale, but
> if there isn't a negotiation and agreement on locale behaviors, having
> the request fail when a locale is not supported is necessary for some
> services to be viable.
> It might also be the case that between the time of the negotiation and
> the execution of the actual request a locale might be removed.
> 
> My service uses another service for Chinese support, and after
> negotiating locales and accepting chinese, the chinese service goes
> off-line. If I continue processing it won't be in Chinese. It might be
> better to fail the request.
> 
> 
> Some definition for a successful match and a failing match is needed.
> 
> If en-us is requested and the service has en but not en-us, that might
> be considered successful from a language point of view, but a failure
> with respect to date formats. (mdy vs dmy)
> 
> On the other hand if en-us is requested and the service only offers es
> or zh, then perhaps it should be failed.
> -- 
> -------------------------------------------------------------
> Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
> Xen Master                          http://www.i18nGuy.com
>                          
> XenCraft             http://www.XenCraft.com
> Making e-Business Work Around the World
> -------------------------------------------------------------
> 
>