[Feature Idea] Lint rule to detect bad-faith translations.

[LorisSigrist]

Ok, this is very much non-urgent, but it's theoretically possible with our architecture, so I'm just gonna write it down for later.

If any community members want to take a shot at this feel free!

Problem

The thing keeping most OSS projects from going multilanguage is that maintainers cannot speak most languages, and therefore can't trust or verify any submissions for translations. Instead they have to find volunteers that they trust / pay translators before going multilanguage. Most don't get past this hurdle.

Proposal

Using google-translate / some LLM you could implement some sanity-checks for the content of any messages that we don't quite trust.

• Detect Vulgar Language
• Detect gibberish
• Spellcheck
• Check if the content is a reasonable translation of the source language (probably doable with an LLM)

By running this on PRs, OSS maintainers could have some faith that the translations being submitted are actually made in good faith and of reasonable quality. This would be a killer feature for the Inlang Ecosystem in OSS.

[felixhaeberle]

@LorisSigrist Yep, I also thought about a spell-checker lint rule which calls an API with the message and with #929 (look, issue with 3 digits) – it could even self-correct it!

[samuelstroschein]

@LorisSigrist you tapped into the richness of use cases our infrastructure approach will enable. lint rules are already async under the hood to support API calls in the future. There is even more to come like code lint rules. Eventually @inlang/editor will turn into a full fledged pro tool for translators like Figma is a pro tool for designers.

The problem atm is how to store/use secrets in lint rules or plugins. Until secrets can't be used, any API request is out of scope.

Should we turn this issue into a discusssion/feature request? We won't work on this work several months to come.