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