- From: M.T. Carrasco Benitez <carrasco@innet.lu>
- Date: Fri, 28 Feb 1997 09:15:02 +0100 (MET)
- To: Drazen Kacar <Drazen.Kacar@public.srce.hr>
- cc: misha.wolf@reuters.com, www-international@w3.org, unicode@unicode.org
> Why? If the processing goes into servers, it should be robust. Servers > should treat clients as their worst enemies. :) One should avoid making innecessary ennemies: if the standard says the language label is only in one place, there is no need to be overdefensive. > Must? RFC 2068 in section 14.13 says > > Content-Language = "Content-Language" ":" 1#language-tag > > Suppose I want to put some translated poems on the web. I'd like to > include original also and I think both should be viewed side by side. > Frames are out of the question because I don't want independent scrolling. > I'd put them on one page, probably in a table. That would be a case for > two language tags. This is a bilingual doc, the Content-Language should contain the two languages and the relevant tags should contain the LANG attribute. A monolingual HTML doc must contain *inside* only *one* language label in *one* place in whatever syntax is choose, and this language label must be pick it up by the server and put it in the Content-Language in the header. > > There must be possible to transport (floppies, attached, etc) a document > > with the lang and charset *inside*. Having it as a file name extension > > could be consider *inside* (not a very good solution), but a doubt about a > > directory. > > I doubt also. I do not get the point: transport is unnecessary, directory is a good solution, ... > Of course, I've only stated my preference. I've forgotten to write why I > strongly dislike language information in the file name. I agree. I also dislike language information in the file name; it should be inside. Tomas
Received on Friday, 28 February 1997 03:13:33 UTC