Option to not download translations files on install

[eelkeblok]

Would it make sense to add an option to not download new translation files on install, only on update? (Or maybe I missed something and this is already possible). On our workflow, we frequently run composer install when switching from one branch to another, and it is rarely desired to update translations at that time, so I would like to restrict the behaviour of the plugin to only download translations when doing a composer update. Maybe an important detail is that we check translations into our version control, so that we have a defined set of translations at any given time, and we're not surprised by incoming updated translations at build time.

[FlorentTorregrosa]

Hi,

Thanks for your suggestion and question.

I originally imagined the package to only provide a Composer command to download translations. And also to consider contrib translations the same as vendor and contrib code, to not have to put it under version control.

Listening to Composer events when updating or installing a package allows to add the translations downloading without needing to update workflows of package generation or local setup.

On install or update, the plugin only downloads translations of the packages it installs or updates.

This is to ensure that the translation matching the current version of the downloaded module is there.

If when you switch branch and do a Composer install, it downloads translations, this means that your modules are also changing versions (or new modules are downloaded), I guess?

Maybe an option to introduce is to no more react on Composer events, so translation would be manually downloaded when executing composer drupal:l10n and you can then choose when to execute the command and update the translations in version control.

[eelkeblok]

Makes sense and I see your point about running composer install to switch to different versions. The reason we do choose to check in contrib translations is that, unlike a locked composer package, they are still somewhat of a moving target; translations in the localization server may be accepted at any time, so downloaded translations may change from one build to the next.

We use this package to remove Drupal itself out of the equation when we actually want to download translations (either on maintenance, or when adding a new project); basically, we have all our environments set to only source translations locally (that's our stable "repository" of translations). Only when running maintenance we want to update the translation files, which used to involve temporarily changing the source setting on the development system running the update.

It would probably make sense to add configuration for both downloading on install events and on update events

[FlorentTorregrosa]

they are still somewhat of a moving target

Yep, it is a downside. The translations timestamp is alway changing so Drupal thinks there are constantly new translations.

so downloaded translations may change from one build to the next.

Yes, this is a risk I accept on my projects. Because config (and config translations) is under version control, so when deploying it is imported in the state of the versionned files. And it is ok for me if there are new translations of UI strings.

to remove Drupal itself out of the equation

Same goal :),

Also using stuff like https://github.com/drupal-composer/drupal-security-advisories (integrated in Drush) to not have to have a Drupal running to be able to detect security updates.

we have all our environments set to only source translations locally

Same :) https://gitlab.com/florenttorregrosa-drupal/docker-drupal-project/-/blob/9.x/conf/drupal/default/example.settings.local.php#L89

It would probably make sense to add configuration for both downloading on install events and on update events

Feel free to provide a PR (with tests please).