Transloco: Maintenance: Ts lint / Codelyzer rules

[siddharth1903]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

What is the motivation / use case for changing the behavior?

To enable, better Maintenance and quality, is it possible that we have certain i18n ts lint rules implemented. Example an app should ensure there is no hardcoded string, without the transloco directive

[shaharkazaz]

@Goonersid We won't be able to reach this anytime soon.
You are welcome to open a PR for it :slightly_smiling_face:

[NetanelBasal]

I'm closing the issue. There may be components that you don't want to translate. Thanks for the suggestion.

[siddharth1903]

I'm closing the issue. There may be components that you don't want to translate. Thanks for the suggestion.

can you think of any examples of this.. I would hate my users to see stuff untranslated while the whole app is served in a particular language

[NetanelBasal]

Internal pages, such as an admin module.

[siddharth1903]

Hard to understand why admins are expected to always see content in English. I think 'ts'lint offers a way to ignore a rule enabled, on a specific line. Doesn't this qualify for a similar exclusion comment on the html where the rule has to be ignored. Can't see this as a reason to not implement 'Governance' itself, as it is a nightmare at times to manually verify if each PR has all i18n NFR's in place.
http://codelyzer.com/rules/template-i18n/
can be a good start point

[Coly010]

In a monorepo, this could cause numerous issues.
Not all apps within that monorepo may need to be internationalized, not all apps or libs within the monorepo may use Transloco specifically for their internationalization.

Therefore enforcing any consumer of this library to ensure that all strings are dynamic can be drastic.

It's much much safer and more appropriate if the project consuming the library sets up this rule for their own specific project, rather than enforcing it on everyone.

[siddharth1903]

@Coly010 Extending a codelyzer rule to be available for consumers to ensure no text is un translated is governance. As i stated before, not all developers understand NFR's and DOD's. To the point you stated, here

In a monorepo, this could cause numerous issues.
Not all apps within that monorepo may need to be internationalized, not all apps or libs within the monorepo may use Transloco specifically for their internationalization.

Libraries, each and every one of them extend from the base tslint.json and can also extend from one (or) more rule sets. Library A using a different i18n strategy need not extend from codelyzer/transloco for example. To configure and extend these rules in every library is a valid expectation. To develop these rules for transloco and maintaining it on every library is not. There would be no difference in the kind of rules that govern two libraries using transloco as their i18n strategy

[shaharkazaz]

@Goonersid as I said before, you are more than welcome to develop this rule and open a PR, it's not in our roadmap for now.

[siddharth1903]

@shaharkazaz sure... I see the issue closed.. it's completely fine if it's not planned... Wanted to just know the rationale behind closing... This also doesn't change the fact that the library itself is extremely useful and governance is not a reason why i wouldn't recommend this 😊