Use Symfony's `TranslatorInterface` as the default translation mechanism

[henriquemoody]

Hi @sokil!

I was checking how this package does translations and I noticed that it has its own way of handling translations.

Recently, in Validation, we made the decision of using symfony/translator as the default translation mechanism. We made this decision for a few reasons:

• symfony/translator is the most used package for translations at the moment
• symfony/translator seems to have become the industry standard for providing translations
• symfony/translation-contracts provides us, developers, to only deal with the contracts of symfony/translator without forcing it as a dependency upon our users (whey don't need to install symfony/translator to install our package)

The complications with having our own translation mechanism is that interoperability is bit more difficult. I understand that you provided a SymfonyTranslationDriver, so users can use symfony/translator, but if you consider an user configuring their dependency injection container to use Countries, for example, the configuration is quite verbose, and I can't see the real benefits of this library having its own translation mechanisms.

Could you explain what's your rationale for having your own translation mechanism?

I'd like to suggest a similar approach what we took in our library, use symfony/translation-contracts as a dependency, rely on Symfony\Contracts\Translation\TranslatorInterface. Perhaps, for this library it event makes sense to heavily rely on Symfony Translator, that will make interoperability much easier, IMO.