Feature #101526
closed
Allow configuration to prevent downloading of language packs for specific extensions
0%
Description
Duplicate:
#98394 proposed this feature, but the solution was to implement an event ModifyLanguagePacksEvent, which can be used for the purpose. So it prepared the architecture, but didn't actually supply/solve the feature.
TYPO3 will try to fetch language packs for all installed extensions in all available languages.
This exposes locally installed extensions to the outer world (the language server).
Furthermore, there might be an extension in the wild with same name, leading to unexpected
downloading foreign language packs. Otherwise unnecessary 404 to TYPO3 translation server
will happen.
It would be cool if extensions could be defined to ignore the procedure. E.g. via
Proposed solutions:
a) On extension level, in extensions composer.json:
{
"extra": {
"typo3/cms": {
"updateLanguages": false
}
}
}b) On project level in settings.php, next to defined languages
'EXTCONF' => [
'lang' => [
'availableLanguages' => [
'nl',
'de',
],
'preventUpdateForExtension' => [
'mysitepackage' => ['nl','de'],
'mycustomerext' => ['*']
]
],
],
Both solutions don't contradict and solve different scenarios. The settings.php solution can be used in every case, the extension composer.json solution might be helpful additionally (e.g. for smaller extensions without FE output or a config GUI, that thus only output labels during exception and need no translation).
Updated by J. Peter M. Schuler about 1 year ago
- Is duplicate of Feature #98394: Allow Extension to prevent downloading of language packs added
Updated by Chris Müller about 1 year ago
Hmm, the new event is there for exactly this reason: implement an event listener which prevents the download of translations.
I am using this event in an extension in TER, where no translations are available.
I am using this event in a project to prevent the checking and download of translations for extension keys which start, for example, with "abc_" (project-specific-extensions).
In the PR for the event we discussed also the solution for a composer.json configuration.
So, why another implementation?
Updated by J. Peter M. Schuler about 1 year ago
Not another implementation but a core implementation which just reads configuration.
As this is a rather common case, there shouldn't need to be logic in an extension (or for the install, e.g. in the sitepackage).
Updated by J. Peter M. Schuler about 1 year ago
(premature send)
That is why they and me asked for "allow configuration for", instead of "prepare architecture for". While the event is helpful and necessary as a first step, it won't allow everybody to achieve the goal.
Updated by Garvin Hicking 16 days ago
- Category set to Localization
- Status changed from New to Needs Feedback
IMO having this in a project sitepackage as an event listener would be a good fit. You can re-use sitepackage logic for other projects.
For public extensions, IMO it's a benefit that these cannot opt out of the language handling. And for internal/customer extensions, you usually always have a sitepackage...?
It's not that much code for a PSR-14 event listener. Maybe even a good idea for a public "PSR-14 event listener collections" repository for a few good re-usable listeners that could be shared.
Adding the nested configuration logic like you proposed looks cool, but would be complex to integrate and configured. Parsing a composer.json of every extension on every language update will make it a bit more complex...
What do you think?
Updated by J. Peter M. Schuler 12 days ago
Indeed, looked into it deeper. This can be done in an extension and the defined event allows to just unset some array keys, so implementing (b) can be easily moved to a sitepackage.
(Although I'd rather put it in an extension for reuse across projects, that's why I suggested to add it to the core).
The solution (a) is indeed complex to watch for every update and I get what forbidding opt-out of language updates for public extensions might have a benefit.
So yeah, perhaps just close this , as most won't need it and everybody else can't one-line it themselves.
Updated by Garvin Hicking 11 days ago
- Status changed from Needs Feedback to Closed
Thanks a lot for your specific feedback and thoughts. I'm closing this now when its acceptable :))