Bug #101334


Custom packages translations not working

Added by Eric Chavaillaz 5 months ago. Updated 3 months ago.

Needs Feedback
Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:



I got some problems with custom packages translations in TYPO3 11. I use "typo3/cms-composer-installers v4.0.0-RC1" and my custom extensions are stored in a packages folder at the same level of vendor one. All works fine except the translations for my custom extensions.

All the translations files are located in "my_ext/Resources/Private/Language/filename.xlf". And they are all used via the official viewHelper or the API methods. It is not possible for me to reproduce this in local with DDEV (in local, the server structure is different).

In fact instead of resolve "/var/www/html/vendor/..." TYPO3 search language files in "/var/www/deployment/x.x.x/vendor/..." . It is not possible for the method GeneralUtility::getFileAbsFileName() to resolve it (because this is outside the project or the public path).

Maybe it can help, I have seen a comment in "LocalizationFactory->getParsedData()": // @todo: this (providing an absolute file system path) likely does not work properly anyway in all cases and should rather be deprecated at line 85.

Could it be linked?

As a workaround I have override the method "GeneralUtility::getFileAbsFileName()" to allow composer path (the "getComposerRootPath" part):

public static function getFileAbsFileName($filename)
    $fileName = (string)$filename;
    if ($fileName === '') {
        return '';
    $checkForBackPath = fn (string $fileName): string => $fileName !== '' && static::validPathStr($fileName) ? $fileName : '';

    // Extension "EXT:" path resolving.
    if (PathUtility::isExtensionPath($fileName)) {
        try {
            $fileName = ExtensionManagementUtility::resolvePackagePath($fileName);
        } catch (PackageException) {
            $fileName = '';
        return $checkForBackPath($fileName);

    // Absolute path, but set to blank if not inside allowed directories.
    if (PathUtility::isAbsolutePath($fileName)) {
        if (str_starts_with($fileName, Environment::getProjectPath()) ||
            str_starts_with($fileName, Environment::getPublicPath()) ||
            str_starts_with($filename, Environment::getComposerRootPath())) {
            return $checkForBackPath($fileName);
        return '';

    // Relative path. Prepend with the public web folder.
    $fileName = Environment::getPublicPath() . '/' . $fileName;
    return $checkForBackPath($fileName);

Note that the translations from the core are working as expected.


tree.png (64.6 KB) tree.png Eric Chavaillaz, 2023-07-12 11:46
Actions #1

Updated by Helmut Hummel 5 months ago

  • Status changed from New to Needs Feedback

It is not possible for me to reproduce this in local with DDEV (in local, the server structure is different).

Can you provide some setup with which we can reproduce the issue? I unfortunately don't understand how to trigger what you are seeing.

Actions #2

Updated by Eric Chavaillaz 5 months ago

Here is the structure of the app where the bug occurs:

Did you need more info?

Actions #3

Updated by Eric Harrer 4 months ago

  • Tags set to xlf
Actions #4

Updated by Helmut Hummel 3 months ago

Hm, that is some elaborate directory structure.

can you post the values of Environment::getProjectPath(), Environment::getPublicPath(), Environment::getComposerRootPath()?

Actions #5

Updated by Eric Chavaillaz 3 months ago

Yes, of course I can:

  • project path: /ccv/data/www/int-hpci
  • public path: /ccv/data/www/int-hpci/htdocs
  • composer root path: /ccv/data/deployment/hpciIN/1.0.2

I think the problem is from the composer root path value and the "deployment" part.



Also available in: Atom PDF