Feature #49984
closed
Distribute localization over multiple .xlf files (atm only locallang.xlf)
Added by Christoph Gross almost 11 years ago.
Updated over 4 years ago.
Description
It would be nice to be able to structure the translation by using multiple files instead just one (possibly very big) file (locallang.xlf)
From my understanding this is currently not possible.
Example:
locallang.xlf
locallang_clientform.xlf
locallang_producttypes.xlf
...
this is possible by just adding the full path
<f:translate key="LLL:EXT:fo/Resources/Private/Language/locallang_fo.xml:bar" />
however take a look at how the core handles translations using the translation server and the related files in typo3conf/l10n/. those are splitted by language and should be smaller and better to handle.
that ok for you?
Adding the full path is an option but really blows up the template, I would like to avoid that.
In the current project, I have some validation errors, some countrynames, some productrelated translation, ... that need translation.
The locallang.xlf gets really long and I would prefer a way to divide this nicely by domain.
Would changing this behaviour interfere with the translation server? If yes, then the effort for changing might not be relation to the benefit. If not, I would really like to see this feature and help to implement it if someone could give me some directions.
Well, that would require some kind of configuration.
- Description updated (diff)
- Status changed from New to Needs Feedback
Hi,
was this issue fixed or does it still exists?
As far as I know it still exists. There is no way to use multiple localization files without specifying them explicitly like this:
<f:translate key="LLL:EXT:fo/Resources/Private/Language/locallang_fo.xml:bar" />
It would be nice to split up the translation by model or some other means. Internally those files would need to be merged in one big locallang.xfl.
- Project changed from 534 to TYPO3 Core
- Category set to Extbase
- Status changed from Needs Feedback to New
This sounds more for fluid, but I let it as extbase feature request
- Category changed from Extbase to Extbase + l10n
- Status changed from New to Rejected
I would like to reject this feature request because we try to have less magic in the core. This feature will increase the magic factor as suddenly strings of some files (which ones) can be retrieved from a different file.
I propose to create a custom VH which extends the translation VH and then you can build up any string by yourself, e.g.
<fo:translate key="title" type="model" />
since version 9 you can even overload the namespaces of VH so that you could use the <f:translate /> for that as well.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by