[Translator] Warming up the cache fails when the translator is disabled.

[SanderVerkuil]

[Translator] Warming up the cache fails when the translator is disabled.

[smnandre]

We probably could do something like this to remove the definiton / disable the package in those scenarios..

https://github.com/symfony/symfony/blob/7.2/src/Symfony/Component/Translation/DependencyInjection/DataCollectorTranslatorPass.php

But you won't be able to use UX Translator at all then, as it need a TranslatorBag to generate the translations

[SanderVerkuil]

Yeah, I indeed understand that it would not be able to work. Right now, I'm enabling the translator in CI/CD, which I'm hoping will work. Otherwise, I'll have to write a custom compiler pass to remove/disable that definition myself.

It would also be great to hear how others handle with translations in a test environment and acceptance tests/assertions.

[smnandre]

If you're ok with the "disable" thing, would you try writing a PR about this ?

[SanderVerkuil]

@smnandre Unfortunately only disabling it if the translator is not enabled didn't work. When the framework is enabled, the forms (or validator, or some other bundles that require the translator) are enabled and the translator is disabled, a translator is added which is the IdentityTranslator. In this case, I verify whether the translator is a subclass of the TranslatorBag, as that is actually the element that is required.

Because the TranslationsCacheWarmer is optional, would it also be a possibility to mark the translator as nullable, and rely on autowiring instead of 'hoping' that the translator happens to implement the TranslatorBag interface?

[smnandre]

In this case, I verify whether the translator is a subclass of the TranslatorBag, as that is actually the element that is required.

Yes, this is what i had in mind when mentionning this file : https://github.com/symfony/symfony/blob/7.2/src/Symfony/Component/Translation/DependencyInjection/DataCollectorTranslatorPass.php

I think we could, in the same manner, remove the TranslationCacheWarmer (and a lot of other things probably) in a dedicated compiler pass.

After, i wonder in term of DX ... that could be a bit hard to explain this.

Could we add a "canBeDisabled" in the config, so for instance you would disable it when needed ?
Would this solve your use case ?

Because in fact TranslationCacheWarmer is not really optional... without it the JS files would not be generated :|