# Symfony Translation NEXT LEVEL
## Features
- Remote Storage via des adapters à la Messenger
- Loco en prio pour la PR principale
- Transifex,
- Commandes translation:push et translation:pull
- par défaut on écrit que les nouvelles trads téléchargées et on laisse les existantes tranquilles
- `--force` pour forcer l'écriture des trad téléchargées en local (créé le s nouvelles trad et update les existantes)
- `--delete-obsolete` => supprime les clés obsolètes : message de warning "êtes vous sûr d'avoir pull avant ?"
- Arguments `domains` & `locales` (ARRAY | OPTIONAL) pour filtrer les translations à sync.
- Profiler (à retravailler en 5.0)
- retirer le sync avec les remotes par défaut. Le profile n'ecrit plus que dans les fichiers locaux
## Planning
1. Ouvrir une issue globale pour lister les features (remote storages, commandes, profiler)
2. Ouvrir une PR pour proposer l'ajout du Profiler
3. Ouvrir une PR pour implémenter les storages sans adapters
4. Ouvrir une PR pour ajouter un ou deux adapter (loco et transifex)
5. Ouvrir une PR pour ajouter les commandes
I open this issue in collaboration with @odolbeau, who has been working on [php-translation](https://github.com/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](https://github.com/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:
```yaml
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.
### Profiler
We also want to improve the translation panel of Symfony Profiler. We would like to transform it from a reading panel to an acting panel.
We would like to improve the third tab to let developers select missing translations. Then by pressing a button, the missing translations would automatically be written in local files.
This can avoid us opening large translation files that nobody likes to read.
Contrary to the available panel in php-translation/symfony-bundle, we will only provide the possibility to add/edit messages to local files.
## Screenshots for Profiler
Multi selection in missing messages table

Edit message in existing messages table (sync button will not exists anymore)

## To Do
- [ ] Add Profiler panel to allow developer avoid edit XLIFF files as much as possible (nobody likes editing XLIFF files manually)
- [ ] Implement Remote Storages into Translation component
- [ ] Plug it into FrameworkBundle
- [ ] Implement Loco and Transifex adapters
- [ ] Implement pull and push commands
- [ ] Tests
- [ ] Documentation