On Wed, 4 Jun 1997, David Goldsmith wrote:
> >I disagree strongly. These are needed in searchable attribute values,
> >protocol error strings, and all sorts of other places where rich text is
> >entirely unacceptable due to it's complexity and lack of searchability.
> >If the only alternative is rich text, I will use MLSF.
>
> Could you explain more why language tagging is needed in these places,
> and in particular why it needs to be an attribute of a substring rather
> than an attribute of the entire string, which could be passed separately?
What about a multi-valued attribute where each value may be in multiple
languages?
What about an error string sent from the server to a blind user where one
of the values causing the error is in a different language from the blind
user's preferred error string language?
What about any multilingual descriptive string which a blind user might
need to hear?
What about the example Pete Resnick of Qualcomm recently stated for
multilingual descriptive text in a personal addressbook on a Macintosh?
Do you think I'd go through the trouble of writing up a detailed proposal
like MLSF, and writing functional source code in the appendix if I didn't
think a solution was necessary?
I've been considering how to put language tags into ACAP at a higher level
for months, and every potential solution had serious drawbacks in terms of
client and protocol complexity -- all of which MLSF eliminates.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT