TYPO3 Core

1, Localization
2. Workspace

Can you point me to the place where this is avertised?
Extbase was started as a Backport from Flow which does have neither of these features, thus the backport does not need them as well.

Mathias Schreiber wrote:

Can you point me to the place where this is avertised?
Extbase was started as a Backport from Flow which does have neither of these features, thus the backport does not need them as well.

It is a core extension

Carsten Bleicker wrote:

It is a core extension

So is form or indexed_search or fe_login.
I don't get your point.

AbstractPlugin (aka pi_base) also had no API for workspaces and/or localization. It is up to the Developer to select the correct data, simply because there is no "right" or "wrong" when it comes to workspaces or localization.
There are usecases where one dev wants a plugin to behave differently than the one of dev 2, simply because they want to see different things.

You could come up with a definition of the expected behaviour - the one that you expect.

Mathias Schreiber wrote:

Carsten Bleicker wrote:

It is a core extension

So is form or indexed_search or fe_login.
I don't get your point.

AbstractPlugin (aka pi_base) also had no API for workspaces and/or localization. It is up to the Developer to select the correct data, simply because there is no "right" or "wrong" when it comes to workspaces or localization.
There are usecases where one dev wants a plugin to behave differently than the one of dev 2, simply because they want to see different things.

You could come up with a definition of the expected behaviour - the one that you expect.

'there is no "right" or "wrong"'
So there is no general deccision possible for "generic" behaviour of translation?
What is the reason for "strict/overlay" translation mode if there is no valid "generic" use case?
For what are hidden fields in this case, if nothing is generic but developer decission?
If the backport does not need them, as you said, why there is an api method typo3/sysext/extbase/Classes/Persistence/Generic/QuerySettingsInterface.php:58

    /**
     * Sets the flag if a  and language overlay should be performed.
     *
     * @param boolean $respectSysLanguage TRUE if a  and language overlay should be performed.
     * @return \TYPO3\CMS\Extbase\Persistence\Generic\QuerySettingsInterface instance of $this to allow method chaining
     * @api
     */
    public function setRespectSysLanguage($respectSysLanguage);

This api method speaks against your definition, that its up to the dev.
In this case it conflicts with your concepts and definitions if respectSysLanguage is an api functionality.

Carsten Bleicker wrote:

So there is no general deccision possible for "generic" behaviour of translation?

We need to differentiate between "possible" and "taken".
I'm pretty sure one could define a generic translation handling (thus it is "possible"), but the decision has not been taken.
This is due to the nature of TYPO3 where everybody tried to give everyone their way.
While this sounds great at first, at a certain point you will run into opposing expected behaviors.
We are in the process of solving this, but setting Extbase to "alpha" has nothing to do with this.

What is the reason for "strict/overlay" translation mode if there is no valid "generic" use case?

The reason is that some people wanted a decision (see above) and tried to come around it with a setting (to make it optional).

For what are hidden fields in this case, if nothing is generic but developer decission?

Which hidden fields are you referring to?

If the backport does not need them, as you said, why there is an api method typo3/sysext/extbase/Classes/Persistence/Generic/QuerySettingsInterface.php:58
[...]

This api method speaks against your definition, that its up to the dev.
In this case it conflicts with your concepts and definitions if respectSysLanguage is an api functionality.

Welcome to open source.
Neither did I write said code, nor do I think having such a setting is a good thing.
Here's why:
In order to fully utilize TYPO3s translation handling you need to turn on/off a lot of switches.
As in the nature of switches, you can turn them on or off in multiple combinations which easily results in chaos.
So you tripped into a trap that someone (do a GIT blame to find out who did it) tried to solve a single usecase here.
And maybe that usecase works.

Still: Extbase in itself works, depending on which part of extbase you use.
Template, Controller and Method lookup work fine.
Persistence needs work and more importantly: cleanup.

But in the end:
Labeling the Extension as alpha just because it does not cover your (current) usecase is not a solution.
In general I consider this ticket a childish and unproductive rant (and thus will close it soon) because I have no idea what the intention of the ticket is besides demotivating the people building the software for free you run your business on.

Consider taking a different approach.

Again, for what is the concept of strict/overlay? One of the switches you are talking about?

"So you tripped into a trap that someone (do a GIT blame to find out who did it) tried to solve a single usecase here."
So you say, there is an existing and known trap in the core i tripped into? Nice to read, that you agree ^^

The intention is, to mark it what it is. A frustrating "Framework in a framework" for a Flow-Software-Compatibility/-Migration wich does not exists anymore.
At least, make it deprecated because the reason it exists for (migration) does not exists anymore.

The intention is: Quality

But hey ... if paranoia seems to be a good reason to close it, go for it ... Welcome to opensource, dude.