TYPO3 Core

well this "feature" request would be a such drastic change, that i do not think it ever will match, furthermore this reduces database-space heavily on big sites...

if you use API functionality you never should have to deal with that - search is a special case, but that's not easy with combined tables too

Yes, of course i'm using API in all places I can, so in summary translation process is good, the problem was only in language-independent search, while it causes merging select results from "pages" and additional subset of "pages" retrieved by "pid" from "pages_language_overlay"...

So let me take it right... There is no technical reasons for existence of that table? Only backward compatibility?

What do you mean "this reduces database-space heavily on big sites"? Since what time reducing DB space is bad :) ?

in pages_language_overlay there are much less fields than you have in pages.

Imagine 20.000 pages + 2 languages, if the overlay needs only 20% of space of the original record (less fields to translate).
Imagine 500 Bytes per record (fictiion value) this would mean: 20k pages * 2 languages * 500byte * 0,8 ==> 16 Megabyte Database overhead.
Additionally you would have much havier index structures on the pages table.

As every page uid is a "pid" - even translated records would be "pids" therefore much more checks in core would have been done to check if the pid is a real pid or not.

In addition, theres backwards compatibility etc...
Currently there is more the tendence to make this feature (external overlay table) available for all records.

So: I (personally) do not think that your request will be handled ever in a 4.x release.

additionally: most of the checks made on page-uids in core are quite plain, tree building etc, too. and there for "relatively" fast. having translations in the same table would have significant speed impact i think.

Understood. Ok then, my curiosity is fully satisfied. My "feature" request can be closed, Thank you for patience.

I'm a little surprised of plans(trend) to make all translations in separated tables, but let it be... Maybe there is sense to make some basic internal search api.

By the way, if your argument is db-space economy - why "tt_content" table uses "same table" paradigm? I'm sure that on any site there is mush more content records than pages.

Hi,
why it's like this I do not know either :) Historical I think...

And it's not planned to separate all translations, just making the feature available to Extensionsauthors for all tables.

regards

Steffen