Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add ide-extension for better i18n handling #1653

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

NilsJacobsen
Copy link

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.

Extract Messages

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)

image

Ootb CLI.

@NilsJacobsen
Copy link
Author

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

image

@NilsJacobsen
Copy link
Author

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.

image

@mifi
Copy link
Owner

mifi commented Jul 11, 2023

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?

"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:

"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
Copy link
Author

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.

image 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
Copy link
Owner

mifi commented Jul 16, 2023

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:

"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
Copy link
Author

@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.👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants