TYPO3 Core

I now have an example of a similar problem, but reversed (see the files in screenshots2.zip).

I have created an Alternative Page Language for a page. I cannot select it in Page view, but I can see it in List view...

.. and you haven't deleted any records? You'll find them in the database (with deleted = 1) but not in any view... (just a thought)

Indeed some elements are destroyed, but unfortunately that doesn't explain everything. I will now upload an updated screeshot (the web site has changed between) and the full output of the SQL query on tt_content for pid=45.

Just as an example, tt_content with uid=42 (and titled "(copy 1)") is not deleted and doesn't appear in the list.

like said. deleted=1 => never shows in list or page Module as well as all(?) core modules.
I think it can be closed.

Indeed deleted elements never show up, but the problem is not as simple here. Juggler, you may not have looked closely at all the exemples I attached with the bug. Would you please reconsider?

As for the part with the Alternative Page Language not showing up, I will open a separate bug.

I'm sorry. :-< (miscount 7 <=> 9)

Could you please
1) provide screenshot of sql-select instead of PDF and have it include 'i18n_parent' and 'sys_language_uid' fields?
2) open single-table view of list-module an let it include [uid] field?

Thx,
Peter

(maybe sys_language_uids have been changed in between?)

l18n_parent is the answer. I am attaching the screenshots you requested, but I checked them first and all the "phantom" elements I was mentioning have a common characteristic: they are translated elements whose language parent was deleted.

So this is the problem: when a content element is deleted, its l18n children have their l18n_parent field set to 0. The bug is then that they don't appear in list view, but appear in the "Non-used elements" tab in the Web > (TV) Page module. I still contend that this is a bug, although maybe not as severe as I indicated. "Translation children" should be marked as deleted when their parent is. I think it makes no sense to have "free-floating" translations.

Glad we tracked it down. I changed summary/title of the bug.
No solution yet though

Taking the opportunity of a Bug Day to go back to that bug. The behaviour of TYPO3 hasn't changed 4 years down the line:

- when deleting a record, translations of that record don't get deleted too, which doesn't make sense.

Actually the same problem occurs when copying/moving: when copying or moving a record, the translation children are not carried around (only the pid of the parent record is changed). Whether this behaviour is desirable when copying is debatable. However when moving it would be quite obvious for the translation records to follow the original.

This would probably require quite some work in TCEmain...

Aaaah, finally I problem I have with one content element (used for testing multilanguage features) has a name!

About what should happen localized versions in my eyes:
In general, localized versions should be copied/moved with their parent, but what if the target page does not exist in all of the languages?

Uschi

Good point. I would say they should be copied along. They will not appear while the page translation still does not exist and will pop into existence once it does. This may seem odd at times, but I think there's some consistency to that behaviour.

Upated the TYPO3 version to 4.2.2 since the bug is still alive.

Could you please consider this bug ?

#0009566

because the problem not only occurs with deleted stuff but also when copy/pasting on other pages.

Thus means, if we act on a default language content. then the same action should be done on all the localised element.

this seems strange beacause I think it's kind of huge bug in localisation handling.

basically the problem seems to start in tcemain line 2663 function copyRecord():

t3lib_BEfunc::getRecordWSOL($table,$uid) is called to fetch the record to be copied.
It seems like theres nothing (even planed, not just not working) to take possible translations into account from there down to line 2727 where tcemain is instanciated again to store the copy.

A possible solution might be to extend remapListedDBRecords() with a check if records stored in $this->copyMappingArray had a translation and to act accordingly.

Is there a solution in sight? We got the same strange issue in a clients project.
Thanks

I've just sent a patch to the dev-list (it resolved a couple of related issues as well) - I'd be glad to get some feedback

attached patch is required by #15452 and #15452 - togehter they resolve copy, move and delete of records with l10n-overlays...

FYI: commited to trunk rev 6192