On 6/7/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 6/7/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
>> Another question: How should languages be handled? Some options:
>> 1. The repository layer knows about languages (i.e., a storage item
>> is identified by a combination of UUID and language).
>>
>> 2. The repository layer UUID is a combination of CMS UUID and
>> language (e.g., news + de -> news_de).
>>
>> 3. UUIDs and languages are not combined, i.e. every translation
>> is identified by its own UUID or the language is part of the UUID.
>> This would either lead to redundance (if the language is stored
>> in the meta data additionally) or convention regarding the syntax
>> of the UUID, so that language queries can be done.
>>
>> IMO option (1) is the most reasonable, I see no need for abstracting
>> from the language in the repository layer.
>
> Lenya is language-aware. #2 and #3 make that very difficult because
> different sitetrees are needed for each language.
Hmm, I don't understand this implication ...
In all three cases, the sitetree would return a UUID for a given URL.
The difference is only about how the framework accesses the repository
layer, isn't it?
> While Lenya1.3
> makes that possible (you can have as many structures as you want, and
> they could be language-specific), it makes the expected case of the
> same structure for all languages very difficult.
>
> #1 is already implemented. Resources have Translations.
That would also be the case with (2) and (3). It's just about internal
storage, the API wouldn't be affected. Or am I missing something?
If each Resource has only one language (using either #2 or #3), each
language must maintain separate structures (more work, more code, more
bugs), and some possibilities of having multiple and default
Translations disappear.
Start with:
UNID=0021(DefaultLanguage="en")/Translation(Language="en")/contentfile
Every request uses "en".
Now add Translation(Language="de").
German uses "de"; all others use "en".
More importantly, no changes to Structures, XSL, or Documents were
required. If the visitor uses "de", the "de" Translation is used. If
the "de" Translation is deleted, it defaults back to "en".
The SitetreeGenerator builds the sitetree from the Resources that
exist for the current language, or have a defaultLanguage that exists.
Since the example "0021" has a defaultLanguage, it would exist in the
sitetree for all languages.
There could also be:
UNID=0022(No Default Language)
/Translation(Language="en")
/Translation(Language="de")
Only the English and German sitetrees would contain this Resource (and
its children if using a Structure). The moment
Translation(Language="ru") is created/published, the Resource would
appear in Russian sitetrees, without updating structures.
This also affects graphics. Setting the default language for the
homepagetitle.gif to "en" shows a graphic like "My Company". Add an
"ru" Translation, and Russians see their own graphic. That could be
important when certain colors or symbols have negative connotations in
certain countries.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
