Subject: Examples in Section 4.2.10 (LANGUAGE parameter)

From: [email-masked] (Roger D)
Date: Fri, 13 Jul 2001 16:04:34 -0400

Section 4.2.10 on the LANGUAGE parameter currently contains:

   Example:

        SUMMARY;LANGUAGE=us-EN:Company Holiday Party

        LOCATION;LANGUAGE=en:Germany
        LOCATION;LANGUAGE=no:Tyskland

   The following example makes use of the Quoted-Printable encoding in
   order to represent non-ASCII characters.

        LOCATION;LANGUAGE=da:K=F8benhavn
        LOCATION;LANGUAGE=en:Copenhagen

The SUMMARY example is fine. The LOCATION examples are illegal: the ABNF in sections 4.6.1 and 4.6.2 clearly state that neither as VEVENT not a VTODO can have more than one LOCATION parameter. They are also misleading: they suggest that the intended purpose of the LANGUAGE property parameter is to allow multiple versions of a human-readable text string to be given translated into multiple languages. This is clearly not the case, since for many of the properties which have human-readable text string values (such as SUMMARY, DESCRIPTION, LOCATION, and the CN property of an ATTENDEE) the property cannot occur more than once, and for those (like CATEGORIES and RESOURCES) that can occur more than once, no provision is made for distinguishing which property is a translation of which: if there are multiple LANGUAGE=en and LANGUAGE=da CATEGORIES, and I change or delete one of the English ones, my CUA would have no way of knowing which of the Danish ones needed to be changed or delet!
ed!
.

[Had the intention of the writers of the RFC been to allow multiple versions of a human-readable text string to be given translated into multiple languages, they would presumably have added a property parameter to do so along the following lines:

     LOCATION;TRANSLATION="no:Tyskland";LANGUAGE=en:Germany

with ABNF

     translationparam = "TRANSLATION" "=" DQUOTE translation DQUOTE
                        *("," DQUOTE translation DQUOTE)
     translation = language ":" *QSAFE-CHAR

It would also be necessary to specify that for properties like CATEGORIES and RESOURCES whose value can be a comma separated list, the TRANSLATION property parameter must contain a comma-separated list containing the same number of entries, each being the translation of the corresponding entry in the property value. However, I am NOT proposing this addition, since I suspect very few CUAs could implement it, particularly the user interface required to enter it.]

Presumably the intention of the RFC is simply to allow the attachment of metadata specifying what human language a piece of humen readable text is in, to facilitate operations such as filtering, indexing, or attempts at machine translation by not requiring that they first guess what language the human-readable text is in.

In addition, the second LOCATION example in section 4.2.10 uses Quoted-Printable encoding. Since the standard and recommended encoding for iCal is UTF-8, whould it not be better for the example to use UTF-8?

--Roger
     
__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/