[Zope3-dev] Re: [Zip] Re: [Zip]Re: About Zope3 HTTP-input handling

[Tino Wildenhain]

Hi Heiichiro,

--On Mittwoch, 23. Oktober 2002 14:47 -0700 Heiichiro NAKAMURA 
<nheiich@quantumfusion.com> wrote:

> Hi Tino,
>
>
> On Wed, 23 Oct 2002 22:30:06 +0200
> Tino Wildenhain <tino@wildenhain.de> wrote:
>
>> I actually dont understand the use of more then one locales
>> object in the tree. This looks like you want different parts
>> of the site having different languages and stuff.
>
> That's right. In today's global economy, even a small-to-mid
> company often has deals with several foreign companies.
> So, for instance, in Japan, one company often has different
> contents for each target region (and it's the recent trend
> they want to have contents for other asian countries, Chinese,
> Korean, Vietnamine, etc).
>
> Another point is, it is not rare that the content itself is
> also significantly "localized", so that almost nothing is shared
> (including page template) as the result of effort to satisfy
> audience of different cultural preferences.
> "Different content for different target audience" makes sense
> in today's CRM era ;)
>
> Also, different browser/device often has different set of
> requirements (including encoding setttings, formats, etc) and
> different behaviours (I can't assume HTTP/1.1 as de facto simply
> because many devices don't follow it). Note I don't assume that
> IE/NN are the only major browsers since many different Internet-enabled
> divices are upcomming.
>
Sure. Sure. But the design should not force a way to do it.
I have success for some years now with the overlay language
system. Others may require a solution like you wanted.
The point is - if you enable the system I propose, you can
serve both. Your requirements (only one variant per subpath)
is actually a subset of my requirement (more then one variant
per subpath).

It only depends on the content you provide in a path. If its
mono language it works fine, if its multilanguage - it works fine.

Different content for different target area is good. But its not
useful if you define the target area only by language.
If you have a public site you might choose the target by
decisisions the user makes (server tld, click on Image/Link with
specific area - Europe, Asia, ...)
But even then its usefull if the customer has the choice over the
language (s)he wants to read.

In a closed site, for example a shop system, its easy to tell the
users by their business data. Again, the content schould be provided
in different languages per business region, if possible.

And yes, you can assume HTTP/1.1, since these days its hard to
browse anything with a strict HTTP/1.0 device - see name based
virtual hosts for example.

I also investigated several devices about their compliance to
language-negotiation and found even some otherwise buggy ones
perfectly complient in this respect.

Any yes, you can happy share pagetemplates among different language
representations of the content. You do this by providing
slots for every part of the page which should be filled with text.



Regards
Tino