[TYPO3-mvc] Additional child records in localization

[Ludwig Rafelsberger]

Hi Viktor, 

first a disclaimer: I am not tooo experienced with the core Extbase
classes since I am just a regular user. Although I have had some
pretty long nights debugging my way through it. Therefore: I can only
tell what I understood so far, not guarantee for its correctness.

> …is it possible (and eventually how) in ExtBase to have additioanl
>childs in localization of record?
As far as I can tell, this is not straightforward possible with vanilla
Extbase and typical language setups. Objects are always searched and
fetched ("thawed") from the database using default language
(sys_language_uid = 0) and then overlayed with the current frontend
language. If an object exists only in languages other than the default,
they will just not be available using standard methods. However, the
findByUid() method and all methods utilizing
->setRespectSysLanguage(FALSE) will find such "orphans", except that
the first one will not suffice and other ones will produce duplicates:
They find the default-language record, the french one, the german one
and so on, then all of them are "overlayed" with the current frontend
language, and voilà: you have 5 equal french bottles of wine, where you
just ordered one ;-)

--

Now, enough theory, lets get on to the solutions:

I once faced the same problem, and my approach there was switching
to a fictive default language. That language is NEVER shown in frontend,
but EVERY record needs to have a "parent" in this language. Now, if you
want to have an extra record only in the german localization, just let
your editors enter a record in the default language, then have it
translated ONLY into german. It will not be visible in the other
languages, provided that you set config.sys_language_mode accordingly.
To get that clear: Using that approach, you always need at least TWO
records, one "default-language" and a translated one for each frontend
language where it should show up.
Two tips from my adventure with such a setup:
* It helps editors if they enter the (obligatory! and "unused")
  deault-language records consequently in a usable state (read: fully
  formulated, in the most common language, so that they are
  "translated" by one click at least in that language). 
* In that setup: Do NOT give editors direct access to the language
  field. They will hopelessly screw it up! Let them follow the mantra
  of creating a default-language record and then translating it.

The other option that comes to my mind, is switching away from
single-tree localization to a setup where each language has its own
pagetree and its own Extbase objects. Although that one has drawbacks
like unrelated records (translation agency involved?), nearly impossible
for visitors to switch the "current" page to another language, …


Hope this helps a little, and if a more (core-)experienced developer
has some words on it, I'd be more than happy.

Cheers, 
Ludwig

---------
PS: If your requirements also contain structural differences between the
localizations (like, an object with a m:n connection to, say,
"categories", where those categories differ by language), then keep in
mind that:
* m:n connections always happen via the default-language records. While
  you can set different related (m:n) objects in a translated record,
  those will just not be followed, when using the Typo3DbBackend class
  for persistence shipped with Extbase
* There's an app for that ;-) Contact me, if you need a rough extension
  that makes Extbase objects relations language-aware (for 6.0 and  6.1).