Remove dependency on contao-community-alliance/translator

[fritzmg]

Having a dependency on contao-community-alliance/translator causes additional sub-dependencies, which might prevent the installation of the newest version of this extension (see contao-community-alliance-archive/dependency-container#20 for example).

But as far as I can see, this package does not use the contao-community-alliance/translator anywhere, only the translator of the Core Bundle is used once and that's it. So it appears this is an unnecessary dependency anyway and can be removed?

[discordier]

It is used as the c-c-a translator backports the symfony translator gateway (contao.translation.translator) which became available in contao 4.5. Therefore, as long as Contao 4.4 is supported, there is not so much we can do here and the dep is not obsolete.

We might be able to loosen the dependencies in the various c-c-a libraries but are a little short on man power at the moment (almost all of us are either in holidays or busy with finishing project in order to be able to go to holidays).

[fritzmg]

Since it is only used for translating one single translation key via the translator, it's probably easiest to just access $GLOBALS['TL_LANG'], if you want to stay compatible to Contao 4.4.

[zonky2]

@fritzmg we looked at the problem during the MM-call - but have not yet found an elegant solution...

[fritzmg]

Well, why use it in this package in the first place? As I said, it is only used for one translation. Why not just access that single translation the old way?

[discordier]

Well, why use it in this package in the first place? As I said, it is only used for one translation.

There are 4 translations

Why not just access that single translation the old way?

Because the old way (polluting $GLOBALS) is not the way we want to use, we want to use the objects and interfaces that are made for this.
We could consider dropping support for Contao <4.9 when 4.4 is out of maintenance via a new minor release, which will then render the requirement useless (as Contao has it's own translator since 4.5 which is getting transparently used via the CCA translator).

[fritzmg]

There are 4 translations

The translator is not used for these translations. As I said the translator is only used for exactly one translation:

https://github.com/menatwork/contao-multicolumnwizard-bundle/blob/fb86b9d44886e7777ef0bf139dfbb09f8bf3dc25/src/EventListener/Mcw/ColorPicker.php#L107

[discordier]

You are right, however, this means that the other code locations have been forgotten to adapt, not that the location already correct should be reverted.

[fritzmg]

Because the old way (polluting $GLOBALS) is not the way we want to use

Contao requires you to do that. The usage of the translator does not prevent that.

we want to use the objects and interfaces that are made for this.

Of course, but it seems like a disproportionately high amount of effort to require an additional dependency in order to have a Contao 4.4 compatible translator service, which in turn depends on older dependencies, just to be able to write

$this->translator->trans('MSC.colorpicker', [], 'contao_default');

instead of

$GLOBALS['TL_LANG']['MSC']['colorpicker'];

exactly once.

You are right, however, this means that the other code locations have been forgotten to adapt, not that the location already correct should be reverted.

They have not been forgotten to adapt. There simply is nothing to adapt.

[fritzmg]

Ah, you mean in places like this for example:

https://github.com/menatwork/contao-multicolumnwizard-bundle/blob/e9c6623b94362240c60b71ba2ec8babc402c1ab8/src/Contao/Widgets/MultiColumnWizard.php#L586

Yes, that could be changed to the translator.

[discordier]

Because the old way (polluting $GLOBALS) is not the way we want to use

Contao requires you to do that. The usage of the translator does not prevent that.

I know that the Contao translator is merely a gateway through to good old $GLOBALS, however, reverting using the translator would also deny the possibility to decorate said translator and therefore not use $GLOBALS at all (for OUR! code, not the big pile of legacy Contao 3.5 code).

Of course, but it seems like a disproportionately high amount of effort to require an additional dependency in order to have a Contao 4.4 compatible translator service, which in turn depends on older dependencies, just to be able to write

$this->translator->trans('MSC.colorpicker', [], 'contao_default');

instead of

$GLOBALS['TL_LANG']['MSC']['colorpicker'];

exactly once.

In this extension this is currently ONE location, you are right. However, we use the translator in all our components, making an exception in MCW will not make things better for the majority of our users. So there would be no benefit.

For Contao > 4.5 it should work to add "replace": {"contao-community-alliance/translator": "*"} in your root composer.json and therefore solve your usecase in a better way.

They have not been forgotten to adapt. There simply is nothing to adapt.

As per your last comment, you found one. 😏

[fritzmg]

For Contao > 4.5 it should work to add "replace": {"contao-community-alliance/translator": "*"} in your root composer.json and therefore solve your usecase in a better way.

Haven't thought of that, that does work indeed 👍 😃

Though I agree that a future version of MCW should simply drop the dependency and increase the contao/core-bundle requirement to ^4.5, e.g. once bugfix support for 4.4 has ended in 2 months, as you suggested.

[fritzmg]

Closing in favor of https://github.com/menatwork/contao-multicolumnwizard-bundle/pull/111