Ignore lint rules

[NilsJacobsen]

The ignore lint rule discussion just popped up again.

Problem:

If a project doesn't want to define a language but uses the fallback instead (probably a legacy issue). de_BAY -> de because some phrases might be the same. Then you don't want the lint's to kick in for this language, or for this language in some bundles.

Proposal 1:

Add the ignore pattern (but as we have 3 levels of lint rules we need 3 levels of ignores (variant, message, bundle))

• a) store in MessageBundle ast
• b) store in a separate file

Proposal 2:

Ignore the problem cause automation should be able to fix this.

[samuelstroschein]

this is an issue in ui components. shouldn't it be an issue, or have a separate issue, in the inlang sdk?

as long as the inlang sdk has no possibility to disable lint rules for message bundles/messages/variants, this feature can't be implemented in the ui components

[NilsJacobsen]

Well the issue appears also in the CI so not an UI issue. But I would say it is reasonable to push back fn. Just want to make sure that there are some use cases that demand this.

[jldec]

Why should users have to manage this on a case-by-case basis? Shouldn't the generic missing translation lint rule be smart enough to handle the case when a fallback exists, so that the rule does not get triggered?

[jldec]

related to MESDK-40

[samuelstroschein]

Why should users have to manage this on a case-by-case basis?

Just like every linter has a // @eslint-disable function, disabling lint rules for messages is desirable.

The "identical pattern" lint rule is a good example. Having a branded slogan like en: Just do it.,de: Just do it.`` should likely remain the same for every language. Hence, ignore the identical pattern for the message bundle

[samuelstroschein]

moved to lix validation rules lix validation rules