[TYPO3-core] RFC: Templavoila + Core fixes

Kasper Skårhøj kasper2006 at typo3.com
Tue Mar 14 23:37:26 CET 2006


>
> I now read it - it could do this so fast as I already knew most of  
> it ... the only
> new things for me were:
>
> * Direct 1:1 content-binding using "defLangBinding"

and "config.sys_language_overlay" I suppose.

Yes, those two were also unknown to Dmitry and Robert I suppose...

> * what I can do with TO local processing (i knew about  
> langOverlayMode - but only in DS)
> * HIDE_L10N_SIBLINGS displayCond
> * It was somehow new to me to use langDisable=1 for pages :) but  
> still do translations (only display those
> CE's which have the correct or ALL language set)

This is also a clear difference: Looking at Roberts implementation in  
TemplaVoila he had hidden the language selector if "langDisable" was  
0 (at some point) etc. Again a testimony that we have done things  
differently.


>
> And I have a few points to notice on your document which with I  
> dont quite agree (if that
> counts :) for example I never use langDisable=1 ... even for  
> containers.

It's OK. It can be understood as a matter of taste. Obviously my  
document warns against it. Maybe we could remove that bias and make a  
case for using langDisable=0 for containers. Looking at Roberts code  
I also realized that it was quite optimized for this case (more than  
I thought).

>
> I mean else I would have to insert either 2 really-different  
> (different uid) content elemnts
> into both pages pointing to the translated content elements. I mean  
> the uid of the default-language
> CE #1 (example) which is referenced in lDEF|field|vDEF will not be  
> the same for all languages ...
> so I cant use sys_language_uid=-1 (ALL) for those containers. ...  
> this is nicely shown in the demo
> i have set up for you. read below.
>
> That the referenced content elements are the same in all languages  
> will only be the case if I you
> only insert FCEs which are translated internally (langDisable=0).

I'm still a little unsure about what it is you want. I think we  
should first find out: Are you trying to "translate" or "localize" a  
page?
By translation I mean that the page has the same structure of content  
in both languages. If you are trying to do that I'm positively sure  
that my approach is best not only technically but also usability wise.
If you are trying to localize (that is having a different structure  
in german) you might need to use containers with langDisable=0.

Anyway, what about if you set up a page on your demo site (using my  
un-patched version of TemplavOila!!), put in some content that we can  
preview on the site, then I will build the same page using my concept.

>
>
> Demo of my patch:
> =================
>
> http://think-open.org/kraftb/demo/typo3/
>
> U/P: core / testing
>
> I have created a few pages on which you can try to translate and  
> view the results. (Home n, Download n)
>
> Of course you will have to delete translated CE's completely before  
> you can translate the langOrig again.
>
> The difference why the FCE's (mostly FCE's are inserted) on the  
> Download pages get's displayed differently
> is because of the TSConfig on the Download pages.
>


Some comments:

Home3 page:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 38856 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060314/c13c4866/attachment.tiff 
-------------- next part --------------

I clicked "Create copy ..." link to make a translation and a new  
record was inserted below. When "config.sys_language_overlay = 1" is  
set, the localized record DOES NOT need to be inserted with its own  
reference like you did here. Thats my whole point. You would also  
have to change the language of "Simple text Element" to "Default"
BTW, I can't make the frontend display work here, I gues you didn't  
intend it to...



-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 13364 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060314/c13c4866/attachment-0001.tiff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 19896 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060314/c13c4866/attachment-0002.tiff 
-------------- next part --------------

What you are doing here is another interesting thing (above).  
Basically you just try to display the localized version of a FCE  
container (having Inheritance mode) as if it was a localized record.  
You will however be able to access the german translation of the  
container if you switch "Show page language version" and if the page  
had langDisable=1! But now you don't have langDisable=1 and that  
gives you a problem; namely that it will be impossible to access the  
german fields. Your solution is to display the german fields; I say  
they will confusing for the user trying to understand the page  
composition (try that with 6 languages...).

I think what you are trying to do is a prime example (for me it is at  
least) why you should stay far away from Inheritance and Separate  
modes for container elements: It is simply too complex which options  
there are and it is very likely that you don't need them - and if you  
do there are work arounds.


Anyway, I think we should battle on building pages as suggested above...

About your patch, I couldn't find it. Could you send a diff?

- kasper




>
>
> About my patch:
> ===============
>
> My patch did not revert to the "old" method of letting TV handle  
> the translation but rather modified it
> and combined it with the TCE_main method.
>
> First of all I have to say that a feature (could be bug) I'm  
> missing for a long time is that it would be possible
> to get the UID's of newly created/copied/localized elements from  
> typo3/tce_db.php. I think you must say that it is
> a flaw that an application which has a link to tce_db.php and uses  
> it to localize a record for example  can't get
> the UID of the localized CE if there is no API for that. (records  
> must not always be localized from the list or
> page module - TV shows us that. And I would have/have the problem  
> for example that my "Content Table" extension,
> which uses Flexforms similarily like TV to store references to  
> other content elements (in this case the containers
> are table-cells), cant know which UID shall get inserted in a  
> translated table cell.)
>
>
> The API I would suggest and implemented in my patch is to simply  
> add a special paramaeter "&result[..." to the
> returnUrl of tce_db.php
>
> In my patch the returnUrl also has the &source= value pointing to  
> the field which got localized. This allows TV to
> handle the TV-specific part of inserting the localized CE into the  
> specific field (either lEN|field_content|vDEF or
> lDEF|field_content|vEN depending wheter langChildren is 0 or 1)
>
>
> I tought over it and noticed that it might break compatibility with  
> other extensions using tce_db.php and setting
> &result to their own value in the returnUrl - I can avoid this by  
> making the append of this string configurable.
>
>
>
>
>
> greets,
> Bernhard
> _______________________________________________
> 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




More information about the TYPO3-team-core mailing list