Support for Drupal 8 logger API

BTW found in #2228763: Create a comment-type config entity and use that as comment bundles, require selection in field settings form, not sure where was it introduced.

Tracked down #1289536: Switch Watchdog to a PSR-3 logging framework as the source of the logger stuff. Left this comment there.

I'm very puzzled by this change or more precisely the lack of thought could have went into considering the translation friendliness, if we even continue to care about that?

1. First of all, this new system had no potx issue opened to support text extraction (now I opened at #2285063: Support for Drupal 8 logger API).

2. Second, the change log mentions methods like notice() and error() which are not defined here, OTOH a log() method is defined which takes a level but that is not mentioned in the change notice.

3. This now supports two possible log string formats. Its unclear to me how that affects translations/translators. Will they get the PSR log format exposed to them? The transformed format? Should we do the same transformation on the potx side?

Answers to some of these questions would be required to even start implementing #2285063: Support for Drupal 8 logger API. Thanks!

Retitle to be a better explanation.

Nonononono! No! We don't translate messages in logging because of multilingual sites. You would be totally capable of managing an e-commerce site with Hungarian, Arabic and Chinese interfaces but probably not able to debug errors with messages in Hungarian, Arabic and Chinese. So we store the messages and the placeholder values separately for translation later and then can translate it for the language of your choice, eg. German for you, Arabic for your colleague who's mother tongue is Arabic to help figure out the issue. We are doing this for several major Drupal releases starting from Drupal 6.

See http://cgit.drupalcode.org/potx/tree/potx.inc?h=6.x-3.x#n286 and http://cgit.drupalcode.org/potx/tree/potx.inc?h=6.x-3.x#n905 (both the type and message are translated when displayed so both are extracted).

So we need to reproduce this kind of approach somehow to the current logging, IF it still translates the messages on display in dblog that is. And looking at DbLogController, we do

        // Messages without variables or user specified text.
        if ($dblog->variables === 'N;') {
          $message = $dblog->message;
        }
        // Message to translate with injected variables.
        else {
          $message = $this->t($dblog->message, unserialize($dblog->variables));
        }
        if (isset($dblog->wid)) {
          // Truncate link_text to 56 chars of message.
          $log_text = Unicode::truncate(Xss::filter($message, array()), 56, TRUE, TRUE);
          $message = $this->l($log_text, 'dblog.event',  array('event_id' => $dblog->wid), array('html' => TRUE));
        }

       // .....
       $this->t($dblog->type)

One could say that if there are no variables that does not mean there should be no t(), that is a bug to be opened. But mostly the message and the type are translated on display definitely.

Finally, we need to figure out how this relates to the PSR log message format which uses totally different placeholder conventions.

Well, we currently do not even venture into the vendor folder(s) for extraction. I guess we may want to do that for the log messages only. Our other "standard APIs" don't really apply anywhere else. Sounds like we assume / tell module developers to keep using the Drupal scheme, so if we don't parse vendor projects then we are fine storing the string as-is found in the source code without transformation?

So looking at how this is defined (at https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logg...) we would need to find strings in methods names the following:

1. log
2. debug
3. info
4. notice
5. warning
6. error
7. critical
8. alert
9. emergency

I think detection of strings based on these methods will definitely run into several false positives like debug() which clashes with our own testing APIs at least. Not sure if we use the other method names at other places for non-logging things, but given the simplicity of them they very well may be.

Here is a start for what this looks like.

Add log() support. Please review!

Looking at that again, the log() parser may go to an infinite loop if there is no second argument to log(), which may be with false positives.

This should skip false positives. Also added to the format_plural checker with tests for both format_plural and formatPlural uses.

Yay, works. Reviews please :)

Oh well, then, we'll fix it in followups if needed.