Bug #91218
closed
Same name of a xlf/xml file can break the frontend
0%
Description
Problem/Description¶
Real world scenario¶
- TYPO3 instance which was updated from 6.2 to 8.7 and so on..
- ext:news (can be any extension) where I use in fluid
<f:translate key="LLL:typo3conf/ext/mysitepackage/Resources/Private/Language/locallang.xml:news_list_more"></f:translate>
Now somebody™ overlook the present EXT:mysitepackage/Resources/Private/Language/locallang.xml and create a new xlf file beside the existing with the same name locallang where I don't put the existing id's from xml.
Result¶
a fluid construct like
<f:link.page pageUid="{settings.listPid}"><f:translate key="LLL:typo3conf/ext/mysitepackage/Resources/Private/Language/locallang.xml:news_list_more"></f:translate></f:link.page>
is rendered as self-closing A-tag like
<a href="/asdfasf/" />
which breaks the DOM because the id "news_list_more" can not be found in the xlf file. Seems like xlf has priority over xml like it is per default in \TYPO3\CMS\Core\Localization\LanguageStore::$supportedExtensions.
ToDo(s)¶
- Throw error/exception? Or log problems?
- Prevent breaking a frontend?
Updated by Georg Ringer over 4 years ago
- Status changed from New to Needs Feedback
Updated by Josef Glatz over 4 years ago
- Assignee set to Josef Glatz
I have to answer some questions myself. Please ignore this issue until then^^
Updated by Georg Ringer about 4 years ago
- Status changed from Needs Feedback to Rejected
I am closing this issue because there is no way during rendering to know if an empty string from translation is valid or not. if this is important to an integrator/dev, the default argument needs to be used.
feel free to discuss on slack if still relevant to you
Updated by Josef Glatz about 4 years ago
For reference: it's ok to reject, since only XLF is supported with TYPO3 11