I'm not sure if we need MessageCatalogueProviderInterface here only TranslatorBagInterface is enough, I already started working on this https://gist.github.com/aitboudad/6eed3ff1187bd8930520#file-delegatingloader-php but couldn't find time to complete it :( maybe I provide an initial work this week-end.

@aitboudad Yes, I am not sure yet how we need to design those interfaces.

Let's see what we're aiming at:

The long-term goal is to get a better encapsulation of MessageCatalogues inside the Translator, so that the Translator could use (for example) "inlined" fallback messages.

There are, however, use cases where clients need to access the full set of messages. Currently they can get those from Translator through the TranslatorBagInterface, but that would not work if the Translator only has the "optimized" catalogues available (or it would need to juggle with the "full" and "optimized" catalogues at the same time).

So it would be helpful if the Translator could handoff getCatalogue() calls to some other (internal/helper) class or if clients could query that class directly. Also note that in order to accomplish its main task (see TranslatorInterface), all the Translator would need to have is some implementation of TranslatorBagInterface.

That would also simplify Translator a lot, because most of its code (and the intricate call graph) actually results from loading and caching message catalogues (both on disk and in-memory), even allowing subclasses to override some protected methods.

If the fallback locales were moved to the Provider part as well, the Provider could extend/implement the TranslatorBagInterface. And once we've got rid of the protected methods in Translator (loadCatalogue, initCatalogue, computeFallbackLocales) and remove the "configuration" things (addResource, setFallbackLocales, addLoader...), we'd pretty much be set with Translator using a TranslatorBag and performing the translating part only.

So why do I currently need another interface?

Inside Translator, there were already two distinct parts of code. initializeCacheCatalogue, dumpCatalogue and getFallbackCatalogue are needed for caching only. They will eventually call initializeCatalogue and its sub-methods doLoadCatalogue, loadFallbackCatalogue to do the actual loading. loadCatalogue would dispatch to either part, depending on caching being desired or not.

This naturally led to a decorator-based approach for the Providers. But the cache has at least to be aware of the resources used to correctly separate cached data. Thus, we need MessageCatalogueProviderInterface as a more powerful way of configuring and composing the load-and-cache related parts.

Does that make sense? In what direction should we proceed from here?

@mpdude see #14671

I think we don't need this one: optimized caching is already dealt with on PHP7, where static arrays and static strings are far superior optimization strategies. Thus, no need to do anything more on our side to me.

Closing for the reason given above (and lack of contra-arguments :) )