On Wed, 11 Jun 1997, Martin J. Duerst wrote:
> > Langauge alternatives have very different semantics from multi-valued
> > attributes. The issues are orthogonal.
>
> Can you explain that some more?
Multi-valued attributes have the property that the attribute holds all the
values at an equal weight. When displayed to the user, all values are
shown.
Language alternatives have to be tagged with the primary language and
represent different forms of the same value. In addition, there has
to be a "preferred" or "primary" language which is displayed in the
absence of a match with a preferred language. When displayed to the user,
normally only the best matching alternative is shown.
> Is this error strings sent from the ACAP server, or stored as data?
> In the former, I don't see much of a need for plugin modules (maybe
> with the exception of comparison/sorting/searching functions) in
> ACAP server implementation. On the client side, of course, this is
> much different, but that's not ACAP's concern, this is only between
> the ACAP client and the user.
Yes, I'm referring to ACAP server messages (which are necessary since it's
not possible to predict all errors for all potential implementations).
One specific example raised was a plug-in kerberos module which may not
have an appropriate localized error, even if the server does. Also,
operating system error messages are an issue (even if I have the right set
of ACAP errors for the client's preferred language, that doesn't mean the
OS perror() strings have been localized).
Such cases are far too likely to happen in real life to be ignored.
> > What about mixed language error messages, and alert messages which aren't
> > available in the client's preferred language? I agree that regardless of
> > the solution chosen, the client will need to express a preferred language
> > for error text.
>
> I was thinking about writing an I-D for defining such a thing
> (together with the response of the server), written so that it
> could be easily used/adapted in various IETF protocols that need
> it. Any comments/interest/showstoppers/coauthors?
I've already seen two proposals written up to do this in the IMAP/ACAP
context.
> But one of the dangers of MLSF, or similar tagging formats,
> is that some other group thinks "we need language information,
> because of RFC 2130, why not just take the tags from ACAP, and
> we are done. The consequence of this may be that that protocol
> doesn't really discuss the needs for language tags in the
> corresponding context, and the interaction with other protocol
> elements.
Yes. Such a proposal needs clear guidelines for when it should be used.
I think the -01 version of MLSF is a bit better than the -00 version.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT