Hey!

I think @rvanlaak has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

@welcoMattic Do you have time to answer Nicolas's question? Is it ready to be merged then?

Thank you for MR! I suggest to merge it to 5.4 but not to 6.1 because actually this can be considered as a fix for more obvious behavior. I've also been surprised when discovered the domains are got not from config.

@fabpot I fixed @nicolas-grekas comment, it's ready to merge now, sorry for the delay

@ossinkine we must consider it as a feature, because nothing is properly broken here

According to discussion with @nicolas-grekas, this PR is a bugfix. It's rebased on 5.4

Thank you @welcoMattic.

It seems the problem still persist.

$domains is set from the $provider->getDomains() after reading local translations for all domains (if we don't pass 'domains' command option).
So when the diff occurs we still have unrelated domains pushed to the provider.

Maybe we can handle this issue with something like this ?

$domains = $domainsInput = $input->getOption('domains');
if ($provider instanceof FilteringProvider) {
    $providerDomains = $provider->getDomains();
    if ($providerDomains) {
        $domains = $domains ? array_intersect($domains, $providerDomains) : $providerDomains;
        if (!$domains) {
            $io->error(sprintf('The provider is configured for this domains: "%s", "%s" provided', implode(', ', $providerDomains), implode(', ',$domainsInput) ));
            return Command::FAILURE;
        }
    }
}

$localTranslations = $this->readLocalTranslations($locales, $domains, $this->transPaths);

if (!$domains) {
   $domains = $this->getDomainsFromTranslatorBag($localTranslations);
}

Or maybe we should handle the case in FilteringProvider::write (and FilteringProvider::delete ?), it seems more logical to filter domains here