Subject: CHARSET and LANGUAGE

From: Doug Royer <[email-masked]>
Date: Tue, 19 Oct 1999 17:26:34 -0700

Because it is on the action item list (W-24?) and the SKi project
concerns. Here are issues that I think the were brought up (Please
correct me if I am wrong):

	1) Language of the iCalendar component object.
	2) Charset of the iCalendar component object.
	3) Language participants of an event are expected to understand.

(1) RFC 2445 addresses the issue.

    (iCal 4.2.10) The LANGUAGE parameter
    can be added to TEXT value type properties, overriding the 
    default language. (Specified in MIME header)

    (and later down..)
    For transport in a MIME entity, the Content-Language header field can
    be used to set the default language for the entire body part.
    Otherwise, no default language is assumed.
 
(2) RFC 2445 addresses this issue in the MIME header. If not specified
    in the MIME header, then the object is UTF-8. (iCal 4.1.4).

(3) Not covered in RFC2445 at all.
    I think this is the point of the comments from the SKi project.

-Doug

---

From: David Madeo <[email-masked]>
Date: Wed, 20 Oct 1999 09:39:38 -0400

>     I think this is the point of the comments from the SKi project.

I'd venture a guess that if the title of an event is in Spanish, that's what
I'll hear if I attend.  If I had a hard time reading the title,  because I
didn't recognize the language, then it really doesn't matter if I could find
out that it was Danish or Japanese.

Having said that, there are lots of cases where even if you don't understand
the spoken language, you can get by with alternate means.  If I go to the
latest French movie here in NYC, the audible sound I hear will be French,
with English subtitles.  When I go to the Opera, I hear Italian with
English/Spanish/French subtitles on the little digital display, a sign
language interpreter in the corner and headsets for the blind.  When flying
Air France, they'll say everything in French and repeat it in English.

So I'd agree this is important and useful.

dmadeo

---

From: John Stracke <[email-masked]>
Date: Wed, 20 Oct 1999 12:11:33 -0400

>         3) Language participants of an event are expected to understand.

There might be more than one, actually--for example, if you have a group of
people who are fluent in both English and German, and habitually speak both
interchangably, and they invite someone to their meeting, it would be nice
if it could be made clear what to expect.  Or, more plausibly, you might
have a play which switches languages frequently.

This is an edge case, but it seems like it should be pretty easy to support.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"The Reality Check's in the mail." --L. Peter|
[email-masked]|Deutsch                                      |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 20 Oct 1999 12:13:04 -0400

> out that it was Danish or Japanese.

Ah, but it does matter, because you might be able to delegate to someone who
does know the language.

Plus, there's the problem of cognates: you might look at a title and think it's
in Spanish, but it's actually in Italian.

|eCal Corp.      |Round up the usual disclaimers.              |
[email-masked]|                                             |

---

From: Paul Hill <[email-masked]>
Date: Wed, 20 Oct 1999 11:45:07 -0600

I have been a lurking on the ietf-calendar list for awhile, mostly because I don't
at this time deal with programming event/scheduling/calendar issues, but I thought
I'd jump in with a few comments on language.

Firstly FWIW, language codes are defined in ISO3166. My examples below do
not use those codes (i.e. ES for Español, EN for English).

David Madeo wrote:
> the spoken language, you can get by with alternate means.
>[...]

Okay, so let me offer the following list of possible scenerios and those writing
the standard can work out how the standard covers or does not cover these examples.

1. A river trip in the wilds of Idaho where the language is English.

#1 is simple enough.

2. A ski week in Switzerland with guides availage in French, English, German etc.

The difference between 1 and 2 is that #2 includes many languages.

3. An Opera in Italian with supertitles in English (?, around here they project them on a little
strip _above_ the stage or hanging from the balcony etc.)

#3 has a single secondary language, but #2 has many primary languages

4. An Opera in Italian with Spanish, French, English available through a 'little
digital display'

#4 points out the need for a list of secondary languages and hints at a 'delivery
method' attribute.

5. An international conference where the Calendar entries have all been transalated
into various languages, so forget about guessing from the title (because
a particular calendar received a particular transalation), but the user would want to
know that the speaker is giving the talk in Catalan, but there will be a simultaneous
French and Spanish translation. This would be different than the proceeding of the
conference being published in French, English, Spanish and German (I assume the
languages of the proceedings are outside of this standard, but maybe not, see
next example) 

#5 shows that the language of the calendar entry is no indication of what
will happening with the primary and any secondary languages of the event.
There is a real DIT/DOT distinction (see discussion from last week)
going on here.

6. A board meeting of an American cooperation in L.A. where the presentation are
in English only, but printed versions of the talks are available in Japanese.

Hopefully, #6 is nearly the same as #3, with only the possible description
of the form of the secondary language.

(I'll leave out the scenerio of #5 that include "a presentation from Latin American division
President in Spanish". That could get us into an example of two primary languages
and one secondary)

The multi-lingual conference and the vacation week with multiple languages available,
both seem like real, but complex enough possibilities that would be good to
cover.

-Paul

---

From: Doug Royer <[email-masked]>
Date: Wed, 20 Oct 1999 11:30:31 -0700

> out that it was Danish or Japanese.

1) This is a SKi topic - not an addition to CAP.

Not exactly the same point. If you speak 2 languages and understand
the SUMMARY and DESCRIPTION in Spanish. You might invite your Spanish
speaking friends - only to find out that when you show up that the event
is all in French. They are working on tourist information, not the same
issue as an ISP
or enterprise might face.

---

From: Paul Hill <[email-masked]>
Date: Wed, 20 Oct 1999 15:18:48 -0600

> not use those codes (i.e. ES for Español, EN for English).

Oops, too many ISO standards to keep track of!
As John Klensin pointed out to me, ISO-3166 is not the right standard.
So let's make that ISO-639 see, for example, http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
ISO-3166 is _country_ codes, see
http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
which no doubt would be used elsewhere in this standard.

FWIW, that would be es (Spanish) and en (English), which is not to be
confused with country codes GB (United Kingdom) or ES (Spain).

-Paul

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 21 Oct 1999 10:38:44 +0200

Great summary

We try to keep things simple by delegating interpreting, text rolls, printed
translations etc., to the RESOURCE property.

And use LANGUAGE as the declaration of the main language(s) utilized.  When
it comes down to it, 99% of events will be tagged (or defaulted) to one
language.

ex.

I attend twice a year EU meetings in one working group where we speak
Danish, Swedish and English.  To be honest, we would confine ourselves to
English if any one was to join us with out Scandinavian language skills, but
nevertheless  we would tag this as:

LANGUAGE: Swedish, English, Danish
(no charset implied in this example:-))

If this meeting was dignified enough to merit interpreters, we would tag
them as:

RESOURCE;Interpretation: German, French

and if printed translations of material presented were available we would
tag them as:

RESOURCE; "German, French translations of the marketing plan"

...and of course there is no way you can guarantee that the language of the
summary reflects the main language(s) of the event.
Who ever thinks that has never been to a large European conference.

Greg

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Paul Hill
> Sent: den 20 oktober 1999 19:45
> To: ietf-calendar
> Subject: Re: CHARSET and LANGUAGE
>
>