Filter missingMessages by language

[adil192]

I tried filtering languages to just English and Simplified Chinese, and filtered to only the missing translations.
The current behaviour is to display all strings that have a missing translation in any language, whereas I would only want to see the missing Chinese translations.

• Following add inlang to make the contribution of translations easier saber-notes/saber#598

[NilsJacobsen]

Hi @adil192, we are currently implementing a fix for that, but thanks for submitting this.
Should be fixed this week.

[felixhaeberle]

@adil192 Thank you for spending the time and submitting this issue, it's very informative and helps us a lot on improving your experience with inlang 🙏

As I can see, you have multiple edge cases we are not covering at the moment, so we will improve upon that and make inlang even better with your input!:)

Is there anything you would further suggest in regards to improving the filtering experience, expect of the suggested behavior that the missing message filter reflects on the selected languages?

[NilsJacobsen]

Since @felixhaeberle is also experiencing that issue I want to clarify why this is happening.
The lint reports are tight to the reference language. That means the report is more like a "Hey there is a translation missing for en". But why is that? In the resources the translation is not there so it's also not in the ast. So we have trouble adding that report to a node that is not there.

So now you know where this is coming from. I know that the experince is not good at the moment, so @NiklasBuchfink tried to hack something together to fix this quickly, but it didn't work out. We have not enough context in the report so we were not able to get the relation between the reference message and the different languages. Handling this on the frontend was leading to performance issues so I wanted to discuss if we should add more context to the lint report so we can handle that information in the frontend.

My suggestions is something like:

export type LintReport = {
	id: LintRule["id"]
	level: LintRule["level"]
	message: string
	reference?: ast.LanguageTag
}

With that approach we could possibly handle outdated translations and that kind of stuff.

What do you think? Is there a hard NO to this?

[samuelstroschein]

Let's try to come up with a solution to this issue. A few remarks:

• Extending the AST with an edge case-specific property seems like a mistake.
• Extending the AST with a property that eases the resolution of this edge case AND provides value besides this edge case could be a solution.
• You should have enough context to re-establish the connection to the reference without modifying the AST.
• If the performance issues are related to query(), we should optimize query().

Pseudocode to fix this edge case without changing LintReport

1. The reference message contains the lints of itself.

const referenceMessage = {
   lint: [
     { id: "inlang.missingMessage", level: "error", message: "Missing for language 'DE'" },
     { id: "inlang.missingMessage", level: "error", message: "Missing for language 'FR'" },
   ]
}

2. If the reference message contains inlang.missingMessage, at least one translated message must be undefined

const missingLanguages = languages().map((language) => messages[language] === undefined ? language : undefined)

3. Filter inlang.missingMessage from the reference message to avoid duplicate lints.

---

TBH though, a fix on lints itself would be good.

[NilsJacobsen]

#595

This should be fixed now

@adil192 thanks again for submitting

[samuelstroschein]

I'll mark your reply as answer and close this discussion. Feel free to re-open if the issue persists.