add `inlang` to make the contribution of translations easier

[NilsJacobsen]

Let me know what changes you request for merging this PR.

Description

This pull request adds the possibility for contributors and translators to manage translations in a UI instead of files with no overhead for the maintainers.

To get a UI for translations contained in this repository, an inlang.config.js has been created at the root of the repository. The json files were cleaned and I added the de translations.

Preview

The changes of this PR and a live instance of the editor can be previewed with the following link https://inlang.com/editor/github.com/NilsJacobsen/nostr-how. Note: This link should be changed to point to nostr-how instead of NilsJacobsen after this PR has been merged.

Limitations

Certain actions are slow Inlang is running entirely on git, giving tremendous CI/CD and contribution power to localization (and potentially other verticals -> the next git). That means that the whole nostr-how repo is cloned into the browser which makes certain actions like the initial load and pushing changes slow. Those limitations will be fixed with future releases and require no input from nostr-how.

Badge

If you want to show the contributor the status of the translations, you could add a badge to your readme.

[![translation badge](https://inlang.com/badge?url=github.com/erskingardner/nostr-how)](https://inlang.com/editor/github.com/erskingardner/nostr-how?ref=badge)

Preview the messages on https://inlang.com/github.com/NilsJacobsen/nostr-how .

[vercel[bot]]

Someone is attempting to deploy a commit to a Personal Account owned by @erskingardner on Vercel.

@erskingardner first needs to authorize it.

[erskingardner]

Hey @NilsJacobsen thanks so much for the PR – this looks interesting. I've never heard of inlang but it looks pretty new so that's not too surprising.

Just to make sure that I understand things correctly. Using inlang just makes it easier for translators to update the JSON file portions of the translations, right. It's not built to handle translation of full markdown files. In that regard, it's a replacement for something like Lokalise or Transifex?

I'm guessing the large number of commits on this PR is because of how inlang works? It's no big deal, just want to make sure I get it. I'll just make sure to set up squash and merge on this repo.

I'll leave some comments on the files themselves.

Lastly, any interest in finishing off the german translations by translating the markdown pages? 😄

[NilsJacobsen]

Hey @erskingardner, thanks for the fast reply.

Just to make sure that I understand things correctly. Using inlang just makes it easier for translators to update the JSON file portions of the translations, right. It's not built to handle translation of full markdown files. In that regard, it's a replacement for something like Lokalise or Transifex?

Yes, right now it can handle strings, lints and this week we release variable support. On our list there is definitely markdown support, I would say that should come in the next months. Inlang has some overlap with these tools, but what is interesting about inlang, is that you do not need specific integration work, it just works with the config and opens the bridge to the other inlang tools. Like vs-code extension that gets published this week and soon also automations (Because it's all git-based there is no need to have additional accounts or dev effort to make automations happen).

I could really recommend this video to understand what inlang is about in the long run: https://www.youtube.com/watch?v=vJ3jGgCrz2I

I'm guessing the large number of commits on this PR is because of how inlang works? It's no big deal, just want to make sure I get it. I'll just make sure to set up squash and merge on this repo.

Jap, it's per message change. We initially did that to track the version history of every message. But we are right now discussing if that is really needed.

Lastly, any interest in finishing off the german translations by translating the markdown pages?

You mean Readme.md and Todo.md? Sure why not:)

[erskingardner]

Thanks @NilsJacobsen

You mean Readme.md and Todo.md? Sure why not:)

No, if you look in the /src/routes/pages/en directory, you'll see all the markdown page (in english) that have to be translated to enable us to turn on a specific language. This is actually the main work in prepping a localization for nostr.how.

[NilsJacobsen]

Ah I see, maybe it makes sense to wait for the markdown support then. I have the feeling you could really benefit from what we want to do there too. Especially when it comes to linting separate markdown nodes. (deprication detection ...) I feel like it shouldn't be a big problem to merge the string support first and we reach out to you with the markdown stuff when we are ready. But I also understand when you want to ship new languages as one package.

I would really love to develop markdown support alongside nostr-how.