[TYPO3-core] RFC: IRRE Localization

[Fabrizio Branca]

Hi,

are there any news on this topic? Is there a clean way to localize IRRE 
records now?

Using the appearance option "showPossibleLocalizationRecords" gives me 
to possibility to localize a record. But when reopening the parent 
record the previously localized record shows up in the default langauge 
and the fact that the localization actually exists prevents from 
creating a new localization (the interface simply does nothing when 
clicking on the icon).

Any news here?

Bye,

Fabrizio



On 27.09.2007 00:50, Bernhard Kraft wrote:


> Hello,
>
>
> This is a RFC about IRRE Localization.
>
>
> Probably some of you know or have at least seen my shop-extension in the
> podcast. In this extension I had a feature like IRRE before it was part
> of the core (I called it TCA-Sections - as the same thing what IRRE is
> is called "sections" in the flex-form world).
>
> Now I ported my shop to use IRRE instead of the TCA-Sections as those
> didn't use AJAX and werent that comfortable.
>
>
> But now a customer mourned that he couldn't translate such section/IRRE
> records - and he required this for his application.
>
>
> So I created a first version of IRRE localization.
>
> See the attached patch.
>
>
>
> =====================
> For this to work there are 3 things required:
>
> 1. The table which contains the IRRE records must be localizeable (have
> sys_language_uid field and l18n_parent field - and those properly
> assigned in 'columns' and 'ctrl') - You can test this by trying to
> translate such a record.
>
> 2. The same as above (1.) has to be done for the IRRE records
> themselves. So you must be able to translate an IRRE record (You can
> also test this in List view - by editing an IRRE record directly instead
> as from it's container)
>
> 3. There is an new option "languageMode" introduced for the "inline"
> configuration inside TCA.
>
>
> =====================
> The new option "languageMode" can have 3 possible values:
>
> * "original" --> The translated IRRE container shows the IRRE records of
> its language-parent. You can add and move around the IRRE records - each
> of those changes (also editing) in the translated container will affect
> the original language and all other languages. So this isn't really a
> translation as the same IRRE records get displayed in all
> language-version containers.
>
> * "separate" --> Each translated IRRE container will have it's own
> records. You can have a different amount of IRRE records in each
> language version - there is no correlation between default language and
> translated version of the sub/IRRE records.
>
> * "inherit" --> The translated IRRE container will contain as many
> records as it's language parent did - but not like in "original" mode
> the same records - but rather their "localized" pendants (so l18n_parent
> of those IRRE records is set to the uid of the respective IRRE record in
> the original-language container).
> It is not possible to move around/delete/hide those records in the
> translated container - you can only to this in the orig-language
> container. The changes will affect the alternate-language containers in
> such a way that the order of the records there also changes.
> =====================
>
>
> Those options mostly resemble the options of Flexform-Sections - where
> you could localize via the "lDEF" or the "vDEF" mechanism.
>
> The reason for such a "localization monster" again is that there are
> different requirements for localizing IRRE records.
>
> One customer wants to have a 1:1 translation of every orig-language
> record. Another customer wants to have the option to have more
> sub-records in one language than in another.
>
>
> Only headache comes to my head when I think more about the "inherit"
> mode. Currently in this mode for every record which has no translated
> record existing a translation is created and linked to the original
> record via l18n_parent.
>
> It probably would be better to have "no" translation of the original
> records in the beginning (and just show them as read-only for example)
> but give the user the opportunity (a button) to create a translation of
> such an original-language record in the translated container (Like in
> the "Page" View of an alternate language when 1:1 language binding is
> choosen).
>
> This would probably be the better solution but I wont take hands onto
> Olivers AJAX / DHTML code - as this is better modified by himself as he
> has the knowledge how things work together there ... and I would like to
> discuss this first ....
>
>
>
> So please feel free to comment and test the patch ....
>
> =====================
>
> Here is an example to a TCA config for the new feature - nothing changed
> except the new option "languageMode"
>
> [hh_location] => Array (
> [label] => LLL:EXT:kb_shopconf/locallang_dyn.xml:prop_vendor__location
> [exclude] => 1
> [config] => Array (
> [type] => inline
> [foreign_table] => tx_kbshop_stbl_vendor___location_SECTION
> [foreign_field] => parent
> [languageMode] => inherit
> [appearance] => Array (
> [collapseAll] => 1
> [expandSingle] => 1
> [newRecordLinkAddTitle] => 1
> )
> )
> )
>
>
> =====================
>
>
> PS: Oliver - could you please contact me via skype or ICQ / MSN / gtalk
> - you find all my contact details on my website (think-open.at)
>
> I would like to discuss this topic a litte bit - we could also move to IRC.
>
>
> greets,
> Bernhard