At 12:12 PM 1/5/2003 +0100, you wrote:

beno wrote:

...

Hi; I would like to get the language code from the client's header. I presume this is done with a REQUEST to get_header, but I've been searching without luck for the syntax. Got it?

You can get it with something like:

REQUEST.get('HTTP_ACCEPT_LANGUAGE')

Okay, so I've got this: <dtml-call expr="REQUEST.get('HTTP_ACCEPT_LANGUAGE')"> How do I return the value of the expression to my script? If my language is *en*, how do I return this to use it in redirecting the client? TIA, beno

At 09:10 PM 1/5/2003 +0100, you wrote:

Hello beno,

are you really absolutely sure you don't want to use Localizer?

Hmm. That looks like an excellent product. But I think it's overkill. What I'm doing is developing a product called *Easy Site* which I'm dubbing *CMF for brochureware*. Lots of newbies to Zope struggle with all there is to learn. This is particularly acute if you're not a programmer and are going up that hill, too (I know ;) And I bet many of these newbies, like me, are mainly interested in building small Web sites for their clients who are small businesses (mom-and-pops). These sites only need to be brochureware. Wouldn't it be nice if a newbie to Zope could grab this product and without much customization at all have a site blinking its eyes in a couple of hours (or even minutes)? One that had all sorts of cool bells and whistles? One that would also serve as a tutorial to learn how to do tricks with Zope? That's what I've been building unawares for a couple of years. So...internationalization. All brochureware sites really need is different folders for different languages that are called via whatever the HTTP_HEADER has. These sites don't go out of date because they're never updated (I know ;) But I've figured it out now. Sometimes I think I'm as thick as a brick ;) TIA, beno

At 12:40 AM 1/6/2003 +0100, you wrote:

Hi benno,

--On Sonntag, 5. Januar 2003 07:27 -0400 beno <zope@thewebsons.com> wrote:

...

At 12:12 PM 1/5/2003 +0100, you wrote:

...

beno wrote:

...

Hi; I would like to get the language code from the client's header. I presume this is done with a REQUEST to get_header, but I've been searching without luck for the syntax. Got it?

You can get it with something like:

REQUEST.get('HTTP_ACCEPT_LANGUAGE')

Okay, so I've got this:

<dtml-call expr="REQUEST.get('HTTP_ACCEPT_LANGUAGE')">

How do I return the value of the expression to my script? If my language is *en*, how do I return this to use it in redirecting the client? TIA, beno

Language negotiation is slightly more complicated. Look out for my outdated (because its for DTML) but as starting point for the algorithm still valuabe VaryTag. Please dont use it directly but look at the source for hints. ( http://www.zope.org/Members/tino/Vary_Tag/readme )

In short, you should have an object-manager alike object (like a folder), add ZPT files for content, name them like de.pt, en.pt, ... index_html or if you make a product the default view should take the HTTP_ACCEPT_LANGUAGE header, do the math on the weights, look into its objectIds(), order it with the accept-list from the client and choose the most appropriate which you have and the client wants or at least a default if there is no match. It should then set the return code and HTTP-Headers to tell downstream proxies and the client about the language-negotiation and finally return the Template in question rendered.

Dont forget to set somewhere (for example in REQUEST) the information which language was choosen, so generated output (for example from database) can be localized as well.

This is far more intense than is required by this application. What I'm building is a product I'm dubbing *Easy_Site* which will enable newbies to template sites for small businesses--mom-and-pops. These sites are what is referred to as *brochureware*. They rarely get updated. They rarely need to call output from databases. These are the kind of pages that, once written, you simply forget about. And more than anything, I'm simply trying to build a product that can enthuse newbies about Zope as well as get them up-and-running with an application that does what they need to accomplish today. In fact, this product is my equivalent of a /skel directory in Apache and is what I've been developing for my own use and for my clients over the past 2 years that I've struggled with Zope. So I *know* how valuable it is. I'm just adding a few bells and whistles for fun ;) Also, I've already answered my own question on this one. But it looks like an excellent product for robust applications, and I will remember it for an application I am preparing myself to build where I need such robustness. Thanks ;) beno