I've added some unit tests, and make code more readable, I'll update CHANGELOG and docs when we'll know if this fits into 2.2 or to master

I'd rather not create a new type of LoaderInterface for that.

The problem is that scanning for files drives the process of using the loaders. Instead, there should be a set of loaders that are used. Your database loader would be among these, probably DI based (tagged). Additionally, a list of file-based loaders would be compiled based on the translation files found.

@mpdude other ways of doing this breaks BC

Hm. From the docs:

If you're loading translations from a database, you'll still need a resource file, but it might either be blank or contain a little bit of information about loading those resources from the database. The file is key to trigger the load method on your custom loader.

That sounds like a deliberate design decision and it would be nice to know why it is that (file-centric) way.

IMO This is totally wrong... The reason you want to load translations from DB source, is that you want to generate and edit it easily. This behaviour triggers additional Point of concern that can lead to unneeded work... You always has to create dummy empty files when your remote source have new translations or domains.

Yes, I agree :-).

Currently, the Resource/translations folder is scanned for files and so a list of message domains (basename) + types (file ext) is obtained. The respective loaders are then used to load the messages for the domains.

IMHO there should be another mechanism to figure out how messages for a particular domain that is needed can be loaded. Scanning for files is only one option (easy to use), but additionally a configured loader (like the DB loader in your example) could be tagged (or queried for?) the message domains it can provide.

Update: See the way the Config/Loader/LoaderInterface is defined. That does not 100% fit Translations as the domain and locale have to be taken care of, but basically that allows to have a set of loaders and find the one (or those?) that can load a particular resource - in this case, a message domain + locale set.

some changes for this issue?

I've come across this again recently. IIRC all you need to do is to 1) add your custom loader to the Translator (in the DIC) and 2) add an addResoure call for every locale and domain that finally triggers your loader.

The FrameworkBundle (?) adds the resources based on the files found, but in fact, you don't need the files when you add the resources yourself.

@mpdude Is it still relevant in Symfony 3?

@fabpot I think this is still revelant and I think there is room for improvement here, especially by creating a native PDO based loader for translations. However, to do that would probably require BC breaks given the current implementations of the Translator loaders.

I am pretty sure that you don't need to create these dummy files, just tweak the DIC and add addResource calls to the translator.default.

We have a custom bundle to load messages from a database, and it works without dummy files. So I'd say this can be closed and/or is not relevant for Symfony 3.

(Yes, there is a little issue regarding the loading order of these resources, see #23057.)