Codelyzer: i18n (check-text) returning false positives

[rafaelss95]

Config:

{
  "rules": {
    "i18n": [
      true,
      "check-id",
      "check-text"
    ]
  }
}

@Component({
  template: `
    <button type="button" mat-raised-button color="primary">
      <mat-icon>add</mat-icon> <!-- unexpected failure reported here -->
    </button>
    <button type="button" mat-raised-button color="primary">
      <mat-icon>
        visibility{{ passwordType === 'text' ? '_off' : '' }} <!-- unexpected failure reported here -->
      </mat-icon>
    </button>
  `
})
class Test {}

[jaufgang]

perhaps a config option could be added to provide a list of elements to ignore (eg: ["mat-icon"]).

[rafaelss95]

I'm afraid we can't add this option without breaking changes. Thoughts @mgechev?

[mgechev]

{
  "rules": {
    "i18n": [
      true,
      "check-id",
      "check-text",
      {
        "blacklist": ["mat-icon"]
      }
    ]
  }
}

Looks fine to me.

[jonsamwell]

Any progress on this? Using @mgechev's solution above makes the i18n rule not work at all rather than just ignoring mat-icon elements (using tsling 5.11.0 & codelyzer 4.5.0).

[Karamuto]

Would appreaciate the blacklist rule. As by the moment this produces unnesscassary i18n attributes.

[wescopeland]

This would be awesome, unfortunately the blacklist property seems to break the template-i18n rule entirely. Does anyone happen to have the blacklist property suggested by @mgechev above working..? I'm wondering if there's something obvious I'm missing. Going through the codelyzer source code I don't think a blacklist property on this rule is possible, but I could be mistaken.

To recap, this works but picks up the mat-icon content in a false positive result:

"template-i18n": [true, "check-id", "check-text"]

This causes the rule itself to be inert (defeating the entire point of having the rule in the first place):

"template-i18n": [
  true,
  "check-id",
  "check-text",
  {
    "blacklist": ["mat-icon"]
  }
]

[fulls1z3]

i can also confirm that blacklisting causes the rule to become inert

angular 8.1.3
tslint 5.18.0
codelyzer 5.1.0

[klemenoslaj]

I am pretty sure @mgechev was just replying to @rafaelss95, suggesting a potential "non breaking change" solution and not pointing to the existing solution for the problem at hand.

I however would love to see this rule being updated with blacklist :+1:

[seawave23]

any progress on this? I'm meanwhile thinking about writing a custom linter rule based on that one...