i18n Web

Document localisation that adapts written material rather than single strings

Tags Freemium AI tools AI workflow automation Privacy AI AI translation AI office

What i18n Web is

i18nweb is a service for developers that translates the localisation files behind a site or app, JSON and Markdown included, rather than the pages visitors see.

The official site did not answer, so what follows rests on directory listings instead of the vendor's pages. Those listings describe translations made with large language models that read surrounding context in the localisation strings.

This matters: localisation files are the ones that ship, so a change stays in the repository, unlike a widget that only alters what somebody is shown.

What you can do with it

The description that recurs is translation at file level for developers: hand over JSON and Markdown localisation files and get versions back, with the model reading surrounding context so terms stay consistent.

Listings present it as a way to cut the manual side of internationalisation, where engineers would otherwise keep parallel files for every language and send them out to translators.

No feature list, no count of supported languages, and no pricing could be confirmed, as the site itself never responded.

Who it is for

The audience implied is engineering groups releasing software in more than one language, particularly the point in a cycle where wording has to keep pace with new features.

That placement is inferred from listings rather than stated by the seller, and should be read that way. Teams maintaining localisation files, and projects whose strings live in JSON or Markdown, are the groups the listings name.

Small product teams without a dedicated translator are another case, along with maintainers of open projects whose contributors supply strings in several tongues.

What to watch out for

Nothing on the vendor's own site could be fetched while this was being written, so it all comes from directories. Where a product cannot be inspected, the honest response is to say so rather than describe capability nobody saw.

Translating interface strings by machine fails in a particular way: short strings carry almost no context, so a word correct on one screen may be wrong on the next. A file-level tool cuts the effort without removing the review pass, especially for error messages and legal wording.

Localisation files are full of variables, plural forms, and embedded tags that must survive unchanged. Anything that damages them produces broken screens, so the result deserves comparing with the source before release.

Nobody could read the terms that govern uploads, and localisation files disclose product plans and internal wording. Assuming they are not sensitive would be a guess until those terms are public.

Pros & cons

✓ What we like

It works on the localisation files themselves rather than on rendered pages, so changes persist in the codebase.
JSON and Markdown are named as the supported formats, which matches how many projects store strings.
Context-aware translation is described, which is what keeps terminology consistent across a file.

! What to watch out for

The official site could not be reached, so no feature list, language count, or price could be confirmed.
Short interface strings carry little context and still need a review pass, and upload terms could not be read.