Add inlang to make the contribution of translations easier

[NiklasBuchfink]

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. Furthermore, I added the few missing translations. If you want, I can add a small i18n section to the documentation on the Contributing page.

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/NiklasBuchfink/frigate-hass-integration.
Note: This link should be changed to point to blakeblackshear instead of NiklasBuchfink after this PR has been merged.

Badge

Also, a dynamic badge can be added to the documentation to show the current state of translations. It will work after the configuration is merged. You can see a demo badge rendered based on my fork.

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 frigate-hass-integration 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 frigate-hass-integration.

Preview the messages on https://inlang.com/editor/github.com/NiklasBuchfink/frigate-hass-integration.

[codecov]

Codecov Report

Merging #478 (017d09e) into master (f6a6d4b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #478   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           15        15           
  Lines         1881      1881           
=========================================
  Hits          1881      1881           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[dermotduffy]

@NiklasBuchfink Thank you for the extremely well written PR. A few thoughts:

• First I would really love much greater language cover both of this repo and the card repo -- so anything that makes that easier is welcome in my book.
• It seems that adopting inlang support (and this PR) places no particular requirements on the maintainers to use the "inlang ecosystem", i.e. people who want to can use it, people who don't can do what they like. This is a property I'd like to preserve, so let me know if that's not correct for any reason.
• I had been using the i18n Ally vscode extension. I see there's also an inlang equivalent, although it looks quite a bit more limited in "language management" overall. i18n Ally has some nice features like reporting on keys in use / empty keys / hard-coded strings that might be nice to implement in inlang (both the service itself, and perhaps the extension) if not already present.
• In order to actually contribute edits via inlang it seems the user needs to grant some pretty sweeping rights, and whilst that doesn't pertain to this PR per se, it may discourage people from actually using inlang to prepare language (at least it would discourage me!). Do you have any thoughts on this? I suspect it may be unavoidable given your desired workflow, but a way to limit writes only to select repos would be much more palatable / expected:
  
• Minor: As I'm suspecting you re-use that wonderful PR description, note that your 'the-next-git' link is broken.

[NiklasBuchfink]

@dermotduffy Thanks for sharing your thoughts:

• I have now added the German translation. If you wish, I can also add the configuration to the card repo and add the German translation there. I can also help you update the documentation.
• Yes, you got it right, adding the inlang config allows contributors to optionally use the "inlang ecosystem".
• We are currently working on a successor for the currently unmaintained i18n ally extension. The inlang extension is currently under development and should be ready in the next few weeks. I can give you an update in this thread.
• As suspected, the large authentication scope is required due to the current workflow and desired user experience. But you're right, that might put people off. Maybe there is a solution to this problem with a more elegant way of assigning rights. Especially when contributing to public repositories.
• Thank you for pointing out the broken link

[dermotduffy]

Thank you @NiklasBuchfink ! If you were up to do similar on the card (dev branch) that would be really appreciated.