Log if a file was successfully transliterated

See my MR and the patch. Please review.

This is great, thank you Peter! I just wonder if we should make this configurable and disabled by default then add this in the readme.

If we are using the dblog module and not an external logging service, this could flood the watchdog table for sites having a lot of files to transliterate + we could miss errors in that case (/admin/config/development/logging default configuration keeps 1000 log messages).

A first lightweight way to do it would be to use Settings, so there is no need to go through the overhead of a config form just for this. But as there is a plan to filter by extensions here https://git.drupalcode.org/project/transliterate_existing_files/-/blob/5... and also have verbose here https://git.drupalcode.org/project/transliterate_existing_files/-/blob/5... i think i would just introduce a config form right away so there is no need to migrate settings / have BC later on.

What do you think?
I can introduce the config form in the dev branch if that makes sense.

> If we are using the dblog module and not an external logging service, this could flood the watchdog table

We are already logging the errors. This could flood the watchdog table, too. So maybe a config for both?

> A first lightweight way to do it would be to use Settings

Yes, this would be useful.

We are already logging the errors. This could flood the watchdog table, too. So maybe a config for both?

By default, I would leave the current behaviour: log errors only, it might be the edge case thus not expecting so many logs, and actually it's something that we should be aware of. But you are right, still leave it to the discretion of the person that is using it as there could be many errors in some cases.

I gave it another thought, as it's only meant to be executed with a Drush command we should continue this way instead of config or settings.
To use something common: drush transliterate:existing-files -v|vv|vvv (normal=default,only errors | more verbose=all logs,error/warning and notice/info | debug messages).

This option can then be reflected on logs and CLI messages.

Going to give it a try a bit later.

> By default, I would leave the current behaviour: log errors only, it might be the edge case thus not expecting so many logs, and actually it's something that we should be aware of.

The migrate core module f.e. offers db tables, which are showing the migrated files. Separate from the log. Such a table would be helpful, too. E.g. "files_transliteration_message".

> as it's only meant to be executed with a Drush command

I would not limit it to Drush only. That would remove the possibility of automate the files transliteration process. Please mind update and deploy hooks: https://www.drupal.org/project/transliterate_existing_files/issues/3539028 ✨ Provide a class method for update and deploy hooks Active

Both thoughts are interesting.

Indeed, we are in a migration case here, so it's good to have a persistent dedicated log table to keep track of everything that was done.
This will also give a chance to automate other processes if needed. Like creating redirects after, if the redirect option was not enabled.
Also, no need to have log conditions then.

As to me it's a one shot operation, the MVP kept it close to what migrate is doing, with the CLI. But totally get the reasoning about decoupling it from Drush.

Well, I am not in a migration case here. :) I am transliterating filenames. Files which have been transliterated are good to know for us. Also it would be good to have redirects for such filename transliterations, so search engines won't stumble into 404 http errors.