TYPO3 Core

Same problem here. A translation for a new or edited FCE in any other Workspace than LIVE is not correctly linked to its I18n_parent in the database.

A look to the database: The fields "l18n_parent" and "t3_origuid" of the translated FCE link both to an incorrect ID. In my testcase the default language FCE has the ID 9, the translation has ID 11, but it links to ID 10 as its parent, where the temporary placeholder for FCE in the workspace resides. When I change the referenced in "l18n_parent" and "t3_origuid" to the correct ID (in my case 9) or correct the wrong setting in the "Transl. Original Field" dropdown inside the edit view of the FCE translation, the translation shows up again in the TV-page module and everything is fine again.

I have made a series of commented screenshots to illustrate the problem and attached it.

I reproduced the problem on two different systems:

1: TYPO3 4.2.8, TV 1.3.7 from TER, PHP 5.1.6 on CentOS (not sure about that, not my system)
2: TYPO3 4.2.6, TV 1.3.7 from TER, PHP 5.2.4-2ubuntu5.6, MySQL 5.0.51a-3ubuntu5.4 on an Ubuntu Server 8.04 (with all updates installed)

I think, this affects more people and thus is a serious bug.

are you sure that this is related to TV? This seems more or less a Core-Problem because TV isn't triggered in the first place if you create the localization... so the l10n_parent value is something which is imho handled within the Core and not within TV...

Could you try to "reproduce" it without TV and afterwards give me an update on that?

Edit:
I tested this again: Standard Content Elements are also affected, this is not related to TemplaVoilàs FCEs! Sorry for my incorrect testing. I included a Screenshot to show the INVALID VALUE issue with a HTML CE.

The trick is: The parent Content Element must be new or edited inside the workspace to provoke this behaviour.

Seems so, that TemplaVoilà is not the culprit. Perhaps this bug report should be moved to the right location then.

Could not reproduct this issue in trunk.

Please check if this issue still exists with trunk or 4.4.2, should be fixed since 4.4.1.
I will close this issue if there won't be any feedback soon.