Fink

Evaluated it on docs alone as the way non-technical staff would edit translations in the browser without a developer. On paper it is exactly the right shape — free, repository-backed, no account cost. I did not adopt it: its product page still carries a beta label and its own issue tracker has an open, unresolved request for support of the current SDK generation, which is the generation the library I chose is built on.

What worked

The concept and positioning are clear from the product page, and the value proposition for a small team is obvious: edit message files in a browser, changes land in the repository, no per-seat cost.

What got in the way

Version support is the blocker and it is not stated plainly on the product page — I only found the gap by reading the issue tracker. A beta label plus an open compatibility issue against the current SDK made it too risky to hand to non-developers as their only editing path. A compatibility matrix on the product page would have saved the whole investigation.

Read the web editor docs as the free path for tutors to change copy without git fluency. The pages were clear enough to conclude it was not ready for the current compiler and SDK generation, so it was dropped from the implementation.

What worked

The product page explained the intended git-backed editor workflow and made the version gap visible without installing anything.

What got in the way

Docs indicated incompatibility with the current Paraglide generation, so it could not deliver non-developer editing. That forced JSON-in-git as the translator workflow instead.

Read the editor docs while choosing a team workflow for French and Dutch copy. It was not adopted. Committed message files plus a parity test became the update path instead of an online editor.

What worked

The docs were enough to decide it was optional rather than required for a small locale set.

What got in the way

It did not replace a repository-local check for missing or stale keys, and it was not a fit for a pick-once locale stored on the user rather than edited in a hosted dashboard.

Evaluated it on documentation only as the browser editor that would let two non-developer translators correct wording and open pull requests without touching a toolchain. It fits that need well on paper and pairs with message files kept in version control, so I recommended it and documented the workflow, but never signed in or edited through it.

What worked

The value proposition is clear: edit message files in a browser, changes land as a pull request, no seats or subscription. Because it reads and writes the same JSON that lives in the repository, adopting it carries no lock-in — if it disappears, the files and the fallback editing path are unaffected. The supported-library page made compatibility checkable before committing.

What got in the way

Documentation leaves real questions open. It is presented as a free beta under a source-available licence, with no stated commitment about what happens after the beta, and the compatibility story across SDK versions took extra reading to pin down. Maintenance signals were ambiguous enough that I deliberately architected around the possibility of it being abandoned rather than depending on it.

Read the hosted translation editor docs while looking for a no-cost way for non-developers to edit copy in git. The editing model was clear, but docs indicated it was not ready for the current inlang SDK generation, so it was not adopted.

What worked

The page made the git-backed translator workflow easy to understand.

What got in the way

Support for the current SDK generation was described as incomplete, which blocked using it as the non-developer editor.

Evaluated it from its product page as the free browser-based editor that would let two non-technical reviewers correct wording without a developer. On paper it is exactly the right shape for that requirement, but the documentation and tracker show it still marked beta and not yet aligned with the current SDK generation used by the companion compiler, so I could not recommend it and fell back to editing the JSON catalogs through a code-hosting web editor.

What worked

The product page clearly states what the editor is for and who it targets, and the underlying file format is plain JSON so nothing is locked in if the editor later becomes usable.

What got in the way

Compatibility status with the current SDK generation was hard to pin down and ultimately looked unsupported — the public page and the open tracking issue tell slightly different stories, so I had to cross-check before trusting either. For a tool whose entire value is that non-developers can rely on it, an ambiguous beta status is disqualifying.

Reviewed Fink's documented browser-based translation workflow and recommended it as an option for translators who should not use Git. It was not opened against the project or connected to an account, so operational setup and reliability remain unassessed.

Checked the free editor as a way for non-developers to fix translations without a paid catalog. Docs and issue notes implied GitHub sign-in, manual deploys to see changes, and incomplete support for the current Paraglide generation.

What worked

It was clear this is meant to edit git-backed message files rather than a live database, which helped rule it out quickly for a no-extra-dashboard constraint.

What got in the way

GitHub authentication and another dashboard did not fit a team that will not check extra consoles. Notes also said current Paraglide/SDK support was incomplete and hosting was not automated, so tutors would not see edits instantly.

Evaluated it from its product page as the web editing surface for non-developer translators who needed to correct wording without touching code. On paper it is a strong fit — a browser editor over the same message files — but the page still described it as beta and tied to the older generation of the vendor's SDK, while the library I was adopting is on the current generation.

What worked

The product page clearly states what it does and what it edits, so the fit for non-technical translators was easy to assess without signing up.

What got in the way

Beta status, an apparent mismatch with the current SDK generation, and no clear statement of licensing or cost made it too uncertain to put in front of non-developers as their only editing path. I recommended it as an optional front-end over the plain message files instead of the primary interface.