I'm not sure if we needMessageCatalogueProviderInterface here onlyTranslatorBagInterface is enough, I already started working on thishttps://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 ofMessageCatalogues inside theTranslator, so that theTranslator 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 fromTranslator through theTranslatorBagInterface, but that would not work if theTranslator 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 theTranslator could handoffgetCatalogue() 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 (seeTranslatorInterface), all theTranslator would need to have is some implementation ofTranslatorBagInterface.

That would also simplifyTranslator 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 someprotected methods.

If the fallback locales were moved to theProvider part as well, theProvider could extend/implement theTranslatorBagInterface. And once we've got rid of theprotected methods inTranslator (loadCatalogue,initCatalogue,computeFallbackLocales) and remove the "configuration" things (addResource,setFallbackLocales,addLoader...), we'd pretty much be set withTranslator using aTranslatorBag and performing the translating part only.

So why do I currently need another interface?

InsideTranslator, there were already two distinct parts of code.initializeCacheCatalogue,dumpCatalogue andgetFallbackCatalogue are needed for caching only. They will eventually callinitializeCatalogue and its sub-methodsdoLoadCatalogue,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 needMessageCatalogueProviderInterface 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 :) )