ESlint Rule for catching non-translated strings in codebase

[Rajat Vijay]

Hi Mathesar

@Sean Colsen
this mainly concerns you since you are the reviewer for i18n project

Context

As part of this project, we decided to write an ESlint rule that catches non-translated strings in the FE codebase.

Findings & Current State

There are the following types of strings that need to be translated

1. Raw strings inside the Svelte template.
2. Raw strings inside the script tag of a component that will be rendered inside the template.
3. Raw strings inside the .ts files that will be rendered inside the template.
4. Strings rendered using labelledCount

Raw strings inside the Svelte template

I came across @intlify/eslint-plugin-svelte which takes care of these types of strings.

Raw strings inside the script tag of a component that will be rendered inside the template. & Raw strings inside the .ts files that will be rendered inside the template.

I am not able to figure out a way to specifically find these from the AST generated. It’s specifically hard to differentiate between the strings that are used as unique identifiers versus the strings that will be rendered in the template.

Ex:

const sortDirection = 'ASCENDING'; // Will not be rendered inside the template, hence no need to translate
const emptyStateMessage = 'No tables available';

Strings rendered using labelledCount
These strings are fine since they will be taken care as per the first approach decided here

Question

Do you have any ideas about solving #2 & #3 or we can live with them for now?

[Sean Colsen]

Rajat,

Previously I said:

The rule would work like this:

• Any raw text longer than 2 characters occurring directly in the Svelte template is an error.
• Also any string in JS that looks like UI text is an error. We’d need to get a little smart here. Our logic would never be perfect, but we could get close, still leaving some false positives and maybe some false negatives.

The @intlify/eslint-plugin-svelte package you found seems like a nice way to handle the first case I mention. I expect it will produce more false positives than my suggested approach (e.g. as shown in Pagination.svelte from your screenshot), but I still think it’s worth using. As demonstrated in your screenshot, it would also be good to figure out a way to skip the stories components with the i18n linting.

The second case I mention is similar to your cases 2. and 3., but not strictly equivalent. I wouldn’t expect it to be possible for us to statically analyze our code to determine whether a string will be rendered inside the template. Instead, I’m suggesting we treat strings that look like UI text as linting errors.

For example:

• These strings should FAIL the linting test:

  Foo
  Foo bar
  Foo Bar
  

• These strings should PASS the linting test:

  f
  F
  foo
  foo bar
  foobar
  foo-bar
  foo_bar
  FOO
  FOO_BAR
  FOOBAR
  

As you can probably tell, I don’t have perfect algorithm in-mind for delineating the failure cases from the passing cases. We could use the strings above as a basis for a unit test that would help us begin writing this rule. The fuzzy nature of this problem is part of why I’d like to implement the linting rule before we wrap all our strings. I would expect that we’d identify more edge cases to add to that test corpus as we proceed. Seeing the false positives and false negatives as we work through all the strings will help us hone the rule. After we’re done with our initial pass of wrapping all our strings, we could even consider making a PR to upstream our rule into that package you selected.

​