feat: add ide-extension for better i18n handling

[NilsJacobsen]

Let me know if I need to change something to merge this PR

I added the inlang IDE extension to lossless-cut. Helps with handling translation keys and translation linting.

What did I add?

• inlang.config.js to configure where language translations are
• Added extension to the workspace recommendations (so contributors can use it)

How to use it?

Extract Messages (translations)

Extract Messages (translations) via the Inlang: Extract Message code action.

Inline annotations

You can see translations directly in your code. No back-and-forth looking into the translation files themselves. (code example from lossless-cut)

Ootb CLI.

[NilsJacobsen]

Ohh and btw I used the npx @inlang/cli lint and got 10513 errors.

[NilsJacobsen]

Also found that key: You can customize the file name of the output segment(s) using special variables. which is not pointing on any translation resource.

[mifi]

Also found that key: You can customize the file name of the output segment(s) using special variables. which is not pointing on any translation resource.

I think it's because we use pluralisation, and the IDE extension doesn't seem to support that?

lossless-cut/public/locales/en/translation.json

Line 623 in d496326

"You can customize the file name of the output segment(s) using special variables._one": "You can customize the file name of the output using special variables.",

Extract Messages (translations)

I believe this is similar to what we already have:

lossless-cut/package.json

Line 31 in d496326

"scan-i18n": "i18next --config i18next-parser.config.mjs",

is there any advantage to using this IDE extension instead?

Inline annotations

You can see translations directly in your code. No back-and-forth looking into the translation files themselves. (code example from lossless-cut)

Keep all {{type}} tracks annotates as Keep all . Not sure how useful that is, or am I misunderstanding something?

Ohh and btw I used the npx @inlang/cli lint and got 10513 errors.

I'm open to improving translations by maybe including this into the CI pipeline, however I'm not sure why there are so many errors. What are these errors about? 10000 seems a bit overwhelming to get started on.

[NilsJacobsen]

Hey @mifi, thanks for reviewing the PR.

I think it's because we use pluralisation, and the IDE extension doesn't seem to support that?

You are right, I opened a issue for that. The i18next plugin should parse that correctly and give that information to inlang. -> opral/monorepo#1069

I believe this is similar to what we already have.

The extract feature is comparable to the i18next-parser lib. Extracting with the CMD + . options feel like better DX to me.

is there any advantage to using this IDE extension instead?

Next to extracting there are inline annotations, which show the translation of the reference language. That is extremely helpful when the keys and translations are not the same. Over time the reference translation will change. And I assume that also happened to -> Keep all {{type}} tracks. I picked that example to showcase it.

🤫 there are two devs working fulltime on the ide-extension, you should expect big updates in the next weeks. i18n handling in the ide is just a pain and we try to make the DX as good as possible. When you have opinions. Feel free to join discussions -> https://github.com/inlang/inlang/issues

however I'm not sure why there are so many errors.

At first, there are multiple error types in the standard lint rules. -> https://github.com/inlang/inlang/tree/main/source-code/plugins/standard-lint-rules/

Most likely there are some missing translations for some languages. To further investigate you can use the editor https://inlang.com/editor/github.com/NilsJacobsen/lossless-cut -> based on my fork. You can play around with lint rule and language filters to see where the errors are coming from.

For example, there are 49 missing messages in German, which could lead to a negative experience for your user. In my eyes there is a big business opportunity to fix the errors.

[mifi]

Next to extracting there are inline annotations, which show the translation of the reference language. That is extremely helpful when the keys and translations are not the same. Over time the reference translation will change. And I assume that also happened to -> Keep all {{type}} tracks. I picked that example to showcase it.

Not sure why Keep all {{type}} tracks annotates as Keep all . from the translations file it's:

lossless-cut/public/locales/en/translation.json

Line 141 in d496326

"Discard all {{type}} tracks": "Discard all {{type}} tracks",

I think your inlang project sounds interesting, and it's cool that you guys are trying to improve the DX of i18n.
LosslessCut currently uses weblate which has similar features to inlang. While I'm not opposed to switching from weblate, I feel that inlang is still a bit experimental and I'm not convinced to make a switch yet. but we can keep this open and see in the future if inlang proves to be better than weblate (and with feature-parity).

[NilsJacobsen]

@mifi the problem with the {{}} is indeed a problem with parsing. It's gonna be solved asap.

I know that you are using weblate and that is totally fine. They can be used concurrently: weblate for editor and inlang for CI and ide-extension (soon GitHub actions).

We are currently working on making inlang bulletproof. We can leave this open and I'm gonna update you about big updates regarding the ide-extension.👍