TYPO3 Core

Usecase:
- In our company we have some base extensions that we use in most projects. We use an own poodle server to sync the translations of these extensions across the projects.
- At second sometimes we have third party translators for some languages we don't speak. Before the change we gave them access to the specific extension/project in our private poodle server to translate them.

Jan Delius wrote:

Usecase:
- In our company we have some base extensions that we use in most projects. We use an own poodle server to sync the translations of these extensions across the projects.
- At second sometimes we have third party translators for some languages we don't speak. Before the change we gave them access to the specific extension/project in our private poodle server to translate them.

Would it make sense to provide one additional, dedicated URL for that usecase?

That would be a solution for our case.

When we discussed this a while ago at the T3CS, we preferred the following solution:

Introduce a setting(for example primaryLanguagePackBaseUrl). If set, the LanguagePackService uses this url instead of the default https://typo3.org/fileadmin/ter.

Meanwhile, our requirements for this feature have changed, so it would be nice to modify this base url for each extension(as was possible with the signal).

How about supporting a user function within our preferred solution setting, as is possible for $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling'] ?

I think the easiest solution is to just re-implement the signal as it has been done before. A patch for this is now pending.