[Zope] Re: Internationalization

[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