[TYPO3-core] RFC: Templavoila + Core fixes

Wed Mar 15 09:24:53 CET 2006

>
>> Bottomline:
>> - I think that if you want to place localized records in different
>> vDEF/vDA/vDE then these elements must be understood as independent
>> records with independant content: localizations, not translations.
>> - If you wish to provide translations you should use not use vDEF/ 
>> vDA/
>> vDE, but only vDEF and then use the localization relations to select
>> the correct record for display.
>> - Finally; There is an aspect of taste involved and I don't mind if
>> others wants to use a variant as long as it is technically sound.
>
> Hmm ... I always tought of it to use lDEF/lDA/lETC if you want to  
> have independent
> records ... as then they are not really "linked" together.
> When one uses vDEF,vDA all references for all languages are  
> together in one single
> XML tag/part, or php-subarray (however you see it) without data  
> from any other fields.

Yes, in that sense they are also linked together, but that linking is  
even stronger with langDisable=1 because it is all in one structure.

Another problem with Inheritance: Say you have this:

lDEF / Container / vDEF => 123,124
lDEF / Container / vDA => 456,457
+ 456/457 have translOriginal set to 123/124

If you do that you can freely change the order of the localized  
versions:
lDEF / Container / vDEF => 123,124
lDEF / Container / vDA => 457,456

It is highly unlikely that you want 457 and 456 to be  
translOriginal's of 123,124 while presenting them in another order!  
This is an impossible mistake to make if you go with langDisable=1  
where only lDEF / Container / vDEF is used to render both languages;  
then the default elements defines the order and localizations are  
overlay at rendertime.

>
> I think the traditional way of localization should get used for  
> getting a linkage between
> the CE's (so you know which CE in german is the translation of  
> which CE in the default language)
> but still the order of elements should get derived from their order  
> in the flexform-field.

That is what I call "highly unlikely" need :-) I think localization  
schemes are complex enough (proven by this discussion) and my  
experience from advanced real-world needs (Dassault) is that we must  
recommend the simplest possible way with a good set of features.

Therefore I believe we should eventually recommend the way I suggest  
because I think it is the simplest.

But I don't mind to support other ways if they make some sense (which  
I agree that your view does).

Question is; what do we do now?

>
>
>> (My recommendation:)
>> <field_content_right>
>> 	<vDEF>23</vDEF>
>> 	<vEN></vEN>
>> 	<vDK></vDK>
>> </field_content_right>
>> + translOriginalPointer of 55 and 84 = 23
>> (sys_language_uid of 55 and 84 points to their language of course)
>
> For this to work quite a bit of how TV renders pages in the BE has  
> to get
> changed.
>
> I mean if the 55 and 84 with translOriginalPointer set to 23 are  
> not inserted
> into vEN and vDK then they will not get displayed in the page- 
> module CE areas.

No! The whole difference lies in "config.sys_language_overlay = 1/ 
hideNonTranslated". When that option is set the _default_ elements  
are always selected (23) and _then_ localizations (55 or 84) are  
looked for and if found, overlaid. This even allows you advanced  
merging where eg. the "image" field of a regular tt_content element  
can be inherited from the default record!

It definitely sounds like you have not become familiar with that one  
yet. This is what changes the whole paradigm!

>
>> (The alternative which will work and is OK but will not have a
>> semantic binding between localization):
>> <field_content_right>
>> 	<vDEF>23</vDEF>
>> 	<vEN>55</vEN>
>> 	<vDK>84</vDK>
>> </field_content_right>
>> + translOriginalPointer of 55 and 84 = 0
>> (sys_language_uid of 55 and 84 points to their language of course)
>
> Using this way it will.
>
> I think we should not change the way that TV displays only those  
> elements which get listed
> in a fields final vWHATEVER tag ... no mattter if lWHATEVER vDEF or  
> lDEF vWHATEVER.
>

I didn't understand this, sorry. Could you make a screen shot of what  
TemplaVoila does currrently display and what it should be according  
to you?

>
>
> Using your method you get some kind of hard-binding whilst using  
> roberts way you get some kind
> of soft-linkage where not each localized (rather than translated)  
> CE must be in the same place
> (in meaning of sorting order).

I agree. But as you can see from above I tend to think the "soft- 
linkage" is a source of confusion; why would anyone need an  
individual order for elements that are 1-1 translations of each  
other? That is very theoretical.

>
> In both methods CE's only for one specific language can get  
> created. I don't think TV respects the
> defLangBinding = 1 variable currently. If it would it would be  
> possibe to create a page bound 1:1
> to the default language like it is possible with MTB.

I think TV respects "defLangBinding" by default here!

actually to make a parallel:
- "defLangBinding" = 1 in page module you get a 1-1 relationship =  
how TV currently works
- "defLangBinding" = 0 in page module you get translations but can  
order it independently = how TV suggest should work

If you agree, then we should maybe introduce this option to TV and  
let that swap how the module places references for elements etc. Yes?

Please then, suggest your patch which creates the right behaviour.

-kasper

>
> Or is this already possible using your method ?
>
>
>
> I set up another demo on my server with rc1 as source and TV from  
> todays t3xdev ....
> http://think-open.org/kraftb/demo2/
>
> User: core / testing
>
> Change whatever you want. the DS/TO are in the so named folder ...
> if you like to change TS do this best in one of the templates in  
> the TS folder ...
>
> There is no language menu currently so you will have to add the  
> &L=1/2 variable manually to
> the URL ...
> but the TS-language switch is there ...
>
>
>
> greets,
> Bernhard
> - --
> -  
> ----------------------------------------------------------------------
> "Freiheit ist immer auch die Freiheit des Andersdenkenden"
> Rosa Luxemburg, 1871 - 1919
> -  
> ----------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFEF2eZIl4dkVkDMFkRAikeAJ9KVEbhY7Sq4aTH28ESgVfjNxuBgwCeJyJi
> CmpKmThFDgXU+/T88V0ncyY=
> =Fgtv
> -----END PGP SIGNATURE-----
> _______________________________________________
> TYPO3-team-core mailing list
> TYPO3-team-core at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-core

- kasper

"A contribution a day keeps the fork away"
-------------------------------
kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej |  
gizmo: kasper_typo3