ngPluralize should generate a warning when being asked to use a rule that is not defined

[lgalfaso]

When ngPluralize is being asked to use a rule that is not defined (say few) then it should generate a warning. This helps developers know that a rule is missing

[marclaval]

Hi @lgalfaso , I've had a look at this issue and come up with a fix based on $log.warn. It works but I'm not sure this is the right way to generate a warning. Did you have something different in mind please?

[lgalfaso]

@Mlaval the fix should use $log.warn, if you have a PR, please put one in place and it will get reviewed

[gkalpak]

@lgalfaso: Would be a good idea to use $log.debug instead, so it can be turned off in production ?
I don't think it is any useful to the user.

(Ideally, there should be disabling flags for every $log method, but since there aren't...)

[lgalfaso]

mmm... $log.debug feels too low... maybe $log.info

[gkalpak]

@lgalfaso:
The only reason I suggest debug is that is can be disabled (using $logProvider.debugEnabled(false)) in production.
warn is fine as a logging level, but is not "disablable" (:smile:), so will end up in users' consoles (and that might be undesirable).

[lgalfaso]

@gkalpak maybe what we need is the ability to set the log level ;)

[gkalpak]

ngPluralizeOptions ? 😄

[lgalfaso]

@gkalpak I meant a way to change the log level at $logProvider that is finer than debug-on or debug-off

[gkalpak]

@lgalfaso: Aha ! Pick one: #5072, #8303, #8832

IMO, we should just get rid of debugEnabled() and provide a method to set the log level instead.
But it's a breaking change, so maybe good for 1.4.

We could add the logLevel() method now and deprecate debugEnabled().
Then on 1.4 remove debugEnabled() (so we don't have more than one ways to accomplish the same thing). Migrating should be super easy: Just replacing .debugEnabled(false/true) with .logLevel('log'/'debug').