I open this issue in collaboration with @odolbeau, who has been working on php-translation with @Nyholm, @rvanlaak, me and other contributors for a long time.

Since a few weeks we have been thinking about integrating some of php-translation/symfony-bundle features directly into Symfony.

Why adding new features to the Translation component?

Nowadays, the Symfony Translation component is really useful for translation process at runtime. It reads a bunch of file formats, it extracts automatically most of translation keys from your code.

However, some features are still missing. They could actually be useful for modern applications. Among these features there is the storage of translations messages in dedicated SaaS to make translators (people) independent of your application.

Moreover, the Translation Panel's DX in Symfony Profiler can be enhanced a lot.

At php-translation we have been working on those features for a few years. We think that some of those can get their right place into Symfony.

What are the features that should be added, in our opinion?

Remote Storages

For us, the main feature to implement is Remote Storages. As I said, many modern applications use translation SaaS to manage their texts' localization.

Most of the time, those SaaS provide APIs with which developers can interact to push and pull translations.

This is very useful if your application needs to be translated by external translators. You might want to provide them a ready-to-use GUI tool and ease you to export their work once it is done. Furthermore, using these tools could avoid conflicts in translation files during development.

We would like to build Remote Storages system just as Transports in Symfony Messenger, or Adapters in Symfony Notifier. We will write an interface and let the developers write more Remote Storages if they need it.

Configuration

Let's imagine the following configuration:

framework:
    default_locale: en
    translator:
        default_path: '%kernel.project_dir%/translations'
        fallbacks:
            - en
        enabled: true
        logging: false
        formatter: translator.formatter.default
        cache_dir: '%kernel.cache_dir%/translations'
        paths: {  }
        
        ## Starting from here, it's new config
        remote_storages:
                # All translations in all locales are pushed and pulled to Loco
                loco:
                    dsn: loco://URL?params
                # Translations from domains "messages" & "validators" and only for locales "en" and "fr" are also pushed and pulled to transifex
                transifex:
                    dsn: transifex://URL/?params
                    domains: ['messages', 'validators']
                    locales: ['en', 'fr']

Commands

We will create at least 2 commands to let you interact with translation SaaS APIs.

Push command

bin/console translation:push <remote-storage-name> [--force] [--delete-obsolete] [--domains validators] [--locales en]

This command lets you send your local translations to a Remote Storage API.
By default, we send only new translations.
With --force we send all translations, new included. It will overwrite updated existing remote translations.
With --delete-obsolete we first fetch remote translations, we filter those which do not exist anymore in local files, remove those from remote storage(s), then we send all translations, new included.

Pull command

bin/console translation:pull <remote-storage-name> [--force] [--delete-obsolete] [--domains validators] [--locales en]

This command lets you fetch your remote translations from a Remote Storage API.
By default, we fetch only new translations.
With --force we fetch all translations, new included. It will overwrite updated existing your local translations.
With --delete-obsolete simply remove your local files and recreate those from fetched remote storage(s) data. By using this one, you must be sure that your local files are up to date. We will advert you with a warning message.

Both of these commands can filter messages on domains and/or locales.