llXmlAutoFilename will never find localized files in l10n path
If the parameter $sameLocation in function llXmlAutoFileName is set to false, like it is as default, it will never return a file name.
$location is set to "typo3conf/l10n" and since there is a condition missing, $validatePrefix will never get a path and then the function will always return NULL.
Adding another condition that checks for the l10n path resolves the problem.
Pushing a patch to review in a minute.
[BUGFIX] Properly handle translation file detection
The GeneralUtility::llXmlAutoFileName() method will now also correctly
handle paths to files that are not placed within a known directory (ext,
sysext, test etc.) if the call is made with $sameFile = TRUE.
This allows placing language files in storages like fileadmin.
Releases: master, 6.2
Reviewed-by: Gernot Ploiner <firstname.lastname@example.org>
Tested-by: Gernot Ploiner <email@example.com>
Reviewed-by: Markus Klein <firstname.lastname@example.org>
Tested-by: Markus Klein <email@example.com>
#5 Updated by Thomas Layh over 8 years ago
I am calling the following from inside my xliff translation tool to get the parsed data:
$xliffParser = t3lib_div::makeInstance('t3lib_l10n_parser_Xliff');
$data = $xliffParser->getParsedData($fileRef, $languageKey);
and getParsedData is calling the llXmlAutoFileName function then.
Perhaps I am using the function for something it is not supposed to do, but I don't see a reason why.
#7 Updated by Alexander Stehlik almost 6 years ago
- File languagetest.zip added
After trying to recap, why I watched this issue in the first place, I post some test instructions to make the issue clear.
Copy the files from the attached ZIP into a current master installation.
Then install the testext in the Extension Manager.
Now place the following code in a TypoScript template:
config.language = de page = PAGE page.10 = TEXT page.10.data = LLL:EXT:testext/Resources/Private/Language/locallang.xlf:mylabel page.20 = TEXT page.20.data = LLL:fileadmin/translation/locallang.xlf:mylabel2
You will see that the first label ist translated correctly to German but the second example stays English.
I think you could do a simple cleanup in
GeneralUtility::llXmlAutoFileName() to solve this issue.