Standardize to RFC 5424 log levels

Since the values behind the constants are transparent to module developers, I don't see why we would continue to use or own rather than the standard's. We're calling our logger PSR-3, modules should use PSR-3's interface in the type hint... why add this asterisk to that?

We do not have 'our own' values, we have values consistent with RFC 3164.

PSR-3 does not require using the constant values from the interface - those are just there as examples. Implementors of PSR-3 are free to use whichever constant values they like.

https://github.com/php-fig/log/issues/8 and https://github.com/php-fig/log/pull/11 both attempted to bring PSR-3 into line with common standards, but were rejected. However it's clear from those that the constant values are not considered part of PSR-3 anyway.

Additionally they aren't transparent to module developers, if you implement a logger for syslog etc., then you'd have to convert from the arbitrary strings to the decimal values anyway.

Also note that monolog uses ints: https://github.com/Seldaek/monolog/blob/master/src/Monolog/Logger.php

Created a PR for php-fig/log: https://github.com/php-fig/log/pull/21

My impression is that there is a good level of support for doing that change (which is reasonable, because the vast majority of projects are using the IETF RFC 5424 integer severity levels), but I yet have to figure out the FIG process. Last comment on the PR was to create a separate thread on the mailing list.

Thank for reviving this one! Forgot we still had this mess...

+++ b/core/lib/Drupal/Core/Logger/RfcLogLevel.php
@@ -0,0 +1,94 @@
+      static::EMERGENCY => t('Emergency'),

Don't think this should use t() - does it have to be a static method on this class or could it move elsewhere?

I'd be fine with converting the remaining uses of the WATCHDOG_* constants and removing them in this patch. They are only used internally at this point so I don't consider them part of the module-facing API. (Short section on this in #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?).

Well the only other place that could make sense is introducing a logger.log_levels service, moving this there, and also splitting the mapping logic from LoggerChannel there.
Is it worth doing?

Not sure that's worth doing, or could be a follow-up - it's not the important thing being fixed here.

Could we use TranslationWrapper or Drupal::translation()->translate() though so the dependency is more explicit?

1. +++ b/core/includes/common.inc
   @@ -3360,19 +3361,11 @@ function element_set_attributes(array &$element, array $map) {
    function watchdog_severity_levels() {
   

   Can also drop this as dead code I think.

2. +++ b/core/lib/Drupal/Core/Logger/RfcLoggerTrait.php
   @@ -0,0 +1,83 @@
   + * \Psr\Log\LoggerTrait. Callers of those implementations are responsible of
   

   responsible for

Otherwise looks great now.

@ParisLiakos please open an issue in Drush's queue once this gets committed so we can keep drush in sync. It should be easy to fix - we have watchdog constants isolated in Drupal version specific engines.

Can't see anything else to complain about. so RTBC.

Committed b82e28d and pushed to 8.0.x. Thanks!

https://www.drupal.org/node/2270941 needs updating now

Removed empty file - a9f0c06 and pushed to 8.0.x. Thanks!