- From: Drazen Kacar <Drazen.Kacar@public.srce.hr>
- Date: Fri, 28 Feb 1997 00:35:52 +0100 (MET)
- To: misha.wolf@reuters.com (Misha Wolf)
- Cc: www-international@w3.org, unicode@unicode.org
Misha Wolf wrote: > For a reason I haven't yet understood, Tomas considers that the server should > take this information from inside the HTML document. Others, including me, > suggest that this information belongs outside the document, eg in the file > name: > > home.fr.html > home.de.html > home.zh-cn.html > > That is what has to be done for other files, such as images, eg: > > go-home.fr.gif > go-home.de.gif > go-home.zh-cn.gif > > I don't understand why HTML files should be treated differently. One problem with language labels outside of the document is mirroring. I am not very knowledgeable about mirroring tools and I may be wrong, but I think that none of them saves this information if it's delivered in the header only. You can probably get it in the debug output, but that's all. The same applies to charsets. If I was writing a server with the ability to extract language info from the document and put it in the HTTP header, I'd support all three methods: <HTML LANG=xx> <BODY LANG=xx> <META HTTP-EQUIV="Content-Language" CONTENT="xx"> META method is the most general, because it can have CONTENT="en, de", for example. RFC 2070 does not allow multiple language tags in LANG attribute, I think. As an author, I'd like lang and charset info outside of the document in the directory name, if possible. I like having as little files in a directory as possible and it's sensible to assume that different persons will work on different variants. I'd be happy to have a directory with only one variant. Hmmm... Synchronizing variants could be a big problem and I suppose some kind of RCS could be enforced on innocent authors. RCS which would not accept errorneous HTML would make me very happy >:) Playing with URL rewriting to find files and generate headers is possible with language info in the file name and in the directory name, so this is not a problem, although I don't know if servers today can do it good enough. -- They work 24 hours a day and 256 days a year -- root@fly.cc.fer.hr dave@srce.hr dave@fly.cc.fer.hr
Received on Thursday, 27 February 1997 18:36:21 UTC