TYPO3 Core

If using the environment variable the l10n cache in .build/var/cache/data/l10n does not contain the translation (Screenshot 1).

If the env variable is not set, the cache is under var/cache/ and the l10 cache includes the german translation. (Screenshot 2).

Instead of setting the `TYPO3_PATH_APP` environment variable directly,
have you tried to use following in your extension composer.json to
setup the TYPO3 installation ?

{
    "config": {
        "allow-plugins": {
            "typo3/class-alias-loader": true,
            "typo3/cms-composer-installers": true
        },
        "bin-dir": ".Build/bin",
        "vendor-dir": ".Build/vendor",
    },
    "extra": {
        "typo3/cms": {
            "extension-key": "your_extension_key",
            "web-dir": ".Build/Web" 
        }
    },  
}

That will create a full TYPO3 composer based installation in `.Build/` with `./Build/Web` as "public" folder (document root for ddev for the domain)
and properly bootstrap all path calculations properly ?

At least, this is what we normally use for extensions development (and I'm settupt up my local apache2 on ./Build/Web and never detected an issue.

I'd would stay away of manipulating these environment variables by hand as there are multiple involved and can lead to undesired effects.

Marcus Schwemer wrote in #note-3:

Yes, we have the composer setting like you mentioned it.

But then the directories "var" and "config" will not be in the .Build folder, but in the project root. This is the thing, we want to prevent.

That is impossible since TYPO3 v12 (composer installers 4). Setting the env var lead to exactly the unexpected behaviour you are describing.

The config and var folder have non configurable locations for now.

When I started re-configuring my extensions to have everything located in a .build folder, this was only due to tooling not being able so set exclude paths for uploading to TER, but auto excluding dot files and folders.

Nowadays this is a cosmetic issue. I see good reasons to stick to the defaults, especially since extensions can be the root for a complete TYPO3 project instance.

So what I rather have in mind and what I think makes sense, is making any resource path configurable, beeing it "Configuration/TCA", "Resources/Public" or, "config/sites" or (not really a resource, but could be handled similarly in this context) "var/log"

The whole TYPO3_PATH_* env vars should rather vanish so that it won't be possible any more to break an installation by setting wrong values there.