Is loading the resources immediately in the constructor (here) really necessary (why)? Commenting it out does at least not break tests.

@fabot /@nicolas-grekas does this look sensible? If you basically agree, I probably should rebase it onto 2.7.

Rebased onto 2.7; no modifications were necessary

Thank you@mpdude.

My app has a custom loader to load translations from a REST service. This change broke it.

It broke because I was injecting the translator into the loader and callingaddResource from within it, thus callingaddResourceafter theinitialize method was called.

Now I suspect this is my error, injecting the translator into a loader certainly doesn't sound the right thing to do.

So I was just after confirmation that this is indeed my issue and any tips on the best way to load resources outside of the loader would be greatly received too. I initially thought a compiler pass, but I don't think it's as simple as that? i.e. I couldn't calladdMethodCall('addResource') for instance because I think that only works for an already constructed object.

Note: I have now successfully used a compiler pass to work around this. Haveopened a PR though to highlight the BC break, may decide it's not a use case we need to support but it's there for deciders anyway 👍

Creating a circular reference between the translator and the loader to have the loader reconfiguring the translator regarding what resources should be loaded by the loader is indeed a use case we never intended to support.