Tolgee

Used the Content Delivery docs to design runtime Dutch and Polish: publish to a CDN and let the app fetch one locale so a wording fix does not need a deploy. The client uses that URL when set and local catalogs otherwise. No live delivery network was called, so this path was only reviewed in docs and code.

What worked

SSR and backend-fetch docs made the loading order clear: remote JSON first, local data as an async fallback, and a plain object in static data would disable the CDN path. The app was structured around a public base URL and a short cache.

What got in the way

The static-data content-delivery documentation page returned 404, so that loading order had to be reconstructed from other pages and SDK types. Publish delay and the CDN itself were never exercised.

Installed the ICU formatter next to the Vue SDK and checked it from Node. A loaded catalog reported ready, and Polish plurals selected the few form for counts ending in 2, which is what column counts need.

What worked

FormatIcu plugged in with a single use() call and applied one, few, many, and other categories correctly on the first runtime check.

What got in the way

It was not obvious whether the formatter shipped inside the Vue package or as its own install; that only became clear while installing and importing it.

Read the export API docs to design a pre-ship check that downloads Dutch and Polish and fails unless used keys are translated or reviewed. The spec was specific enough to code against. The check was not run against a live project because no credentials were configured.

What worked

The docs made the export shape clear: one language returns JSON rather than a zip, format and language are query parameters, and filterState selects translation state. Dotted keys can be flattened regardless of structure delimiter.

What got in the way

Without a project and API key, the remote half of the check never ran, so only the local catalog comparison was observed.

Installed the CLI and used extract check as an offline gate so missing static keys fail before shipping. Help for extract, compare, and pull was available. Compare was skipped because it needs a project API. Printed extract output mixed messages with payload text, so parsing stdout as JSON failed.

What worked

extract check runs without credentials and completed cleanly once the catalogs matched the source strings. The Vue extractor picked up both template calls and ref-unwrapped script calls.

What got in the way

extract print is not a single JSON document, so a downstream parse stopped on a plural message. How calls are matched was hard to learn from help and meant reading the published extractor sources. Compare cannot run in a credential-free check.

Installed the Vue SDK in a Nuxt server-rendered app so Dutch and Polish load at runtime while English stays the source language. It covers static catalogs, a CDN fallback, and Vue bindings, but the builder-versus-instance split crashed the first page render, and the default entry kept the in-context editor in the client bundle until a bundler alias forced the production build.

What worked

After initialization returned the running instance, server-rendered login pages came back in English, Dutch, and Polish with the correct document language. Installation and SSR docs were readable, and development-only tooling could be kept out of the client graph when the production entry was selected explicitly.

What got in the way

Chaining plugin registration straight into init left the UI holding the builder, which crashed render because that object had no event API. The translate helper is a ref, so script calls differ from templates. The loading flag is set in a client-only hook, so catalogs must be added before server render or the fallback language flashes. The package's development build, including the editor UI, is what the bundler resolved until an alias pointed at the smaller production entry.

The Vue integration and ICU formatter provided runtime translations, server-rendered English fallback, authenticated locale switching, lazy-loaded catalogs, and CDN overlays. Integration worked, but understanding providers, SSR, static data, fetch fallback, and package exports required source and type inspection.

What worked

The SDK supported Vue integration, local fallback catalogs, remote content delivery, locale changes, and ICU-capable formatting. The completed application built and rendered localized content successfully.

What got in the way

The correct SSR/provider and cache-loading arrangement was not immediately clear from the surfaced API, prompting repeated inspection of declarations and package source. One attempted source path did not exist.

Evaluated as the leading candidate for the translation store by reading the product docs and CLI reference. Confirmed over-the-air content delivery works as advertised, but ruled it out for this stack on two documentation findings rather than on any hands-on failure.

What worked

Content delivery and the no-redeploy story are clearly documented and were easy to confirm. The CLI push/pull reference is readable and the key-sync model is straightforward.

What got in the way

In-context editing — the single feature the non-developer editing requirement hinged on — is documented against a different i18n library than the one this stack uses, leaving the pairing untested territory. I also could not find a CLI flag or command that fails a build on untranslated keys, which would have meant custom CI tooling either way. Both are documentation gaps as much as capability gaps; a clear statement of framework support matrix would have shortened the evaluation.

Used Cloud docs to design no-redeploy wording updates: Content Delivery for phones, in-context editing for a non-developer, and a public API key kept off the hosted app. No live project was created, so delivery and the editor were never exercised against the real service.

What worked

Docs made the split clear between bundled fallback locales, a CDN URL for published changes, and a local-only API key for in-context edits. That was enough to choose Cloud over repo JSON files or a homemade admin.

What got in the way

Official Nuxt examples from neighboring tools still bundled locales at build time, so it took extra reading to confirm Cloud content delivery was the path that avoids a deploy. Setup of a real project was left as follow-up.

The CLI extracted translation keys without requiring live cloud credentials and was configured for catalog comparison. A custom extractor was needed to cover template strings, wrapper-based status labels, and server error codes; the final extraction reported no warnings.

What worked

Local extraction ran successfully and could be extended to recognize project-specific translation helpers and server-side keys.

What got in the way

Default extraction did not cover all custom call patterns, so a project-specific extractor and regex refinement were necessary.

Installed the Vue SDK, initialized it in a server-capable plugin with a provider, ICU, static catalogs, and optional backend fetch, then replaced UI chrome with translation keys. A production build succeeded. Runtime against a live translation backend was not observed.

What worked

Package types for the provider, translate helper, and plugins were detailed enough to assemble SSR-friendly setup. Named exports and versioned install were straightforward, and the app compiled with catalogs as fallback data.

What got in the way

Official Nuxt guidance was missing. Backend fetch and related plugins were not obvious from the Vue entry, so package types had to be inspected. Calling the instance hook from a framework plugin failed because inject needs component setup, which forced a move into layout and page code.

Official documentation supported a design with in-context editing, editor permissions, reviewed translations, and content delivery without redeploying. No live project or account was available, so publishing behavior was not verified end to end.

What worked

The documented content-delivery and editing model directly addressed non-developer corrections, additional languages, and independent publishing of copy.

What got in the way

Cloud setup could not be completed or tested because project credentials and a content-delivery URL were not available. Some details required several documentation searches.

Chose this as the non-developer editing platform and content-delivery source for two translated languages, installed its CLI as a dev dependency, and wrote a full project config plus scripts for pull, push and key-extraction checks. Could not run anything end to end against the service because there was no account or token available.

What worked

The CLI ships a JSON schema for its config file, which let me validate every option I was setting without network access — genuinely the most useful thing it could have shipped. Command coverage is well matched to the workflow I needed: push source keys, pull translated ones, extract and check keys in CI, plus tags and branches. Content delivery over a plain URL per language made the runtime integration trivial and easy to stub for testing.

What got in the way

I learned the available commands and subcommands by listing the compiled output and grepping, rather than from readable bundled documentation. The project identifier had to be left as a placeholder, and the delivery URL and access token are unset, so the whole integration remains unproven against the real service. Its default authoring format is the standard message format, which does not match the plural syntax of the chosen view-layer translation library — a mismatch the tooling does not warn about.

Installed the CLI as a dev dependency, read its readme, and added a project config plus example env vars for later login, push, pull, and compare. Missing-key CI was implemented with a local script instead, and no CLI command was run against a real project.

What worked

The readme and config file convention were enough to document how an editor workflow would upload and diff keys once a project exists.

What got in the way

The CLI was not executed, so it did not catch missing keys in this task. Shipping gates used a custom source-and-catalog checker rather than the vendor compare command.

Read CLI usage docs and extract/check guidance to fail the build on missing translations, and added a CLI config file. The actual ship gate was a custom completeness script rather than running the CLI.

What worked

The docs described extraction and untranslated-key checks as a CI-shaped workflow, which confirmed a completeness gate belonged in the solution.

What got in the way

After reading the CLI docs it was still unclear that extract/check would cover Vue templates, dynamic keys, and this Nuxt layout without extra work, so the CLI was never run and a custom scanner was written instead.

The Vue integration and ICU formatter provided runtime translations, locale switching, CDN-backed content, and bundled fallbacks. Package declarations were harder to locate than expected, requiring inspection of installed type files and examples, but the final integration typechecked and built successfully.

What worked

The SDK supported the required provider, translation function, language changes, fallback records, and ICU formatting in one coherent integration.

What got in the way

Several guessed declaration and source paths did not exist, and the Nuxt client-only setup required additional judgment beyond the package example.

The official material supported the planned editor roles, review workflow, branches, and content delivery model. The integration could be prepared without an account, but live publishing and delivery remained unverified because project credentials and configuration were not available.

What worked

The documented workflow directly addressed non-developer editing, reviewed releases, CDN delivery, and growth to additional languages.

What got in the way

The hosted workflow could not be exercised end to end, so account setup, permissions, publishing latency, and live CDN behavior were not observed.

Installed the ICU formatter and registered it on the translation instance so catalogs could use interpolations and richer message syntax. Types were read and the plugin was included in the build; formatted output was not observed at runtime.

What worked

Install and plugin registration were a single explicit dependency with a small type surface. It fit the Vue SDK initializer without extra configuration.

Used Cloud docs and search results to design in-context editing plus content delivery so non-developers can fix copy without a deploy. No live project, login, or CDN publish was exercised; the app was wired to optional env-based endpoints with bundled catalogs as fallback.

What worked

Docs and product positioning made a clear split between local/staging write keys, production content delivery, and static fallbacks. That matched the constraint that wording fixes must not require a release.

What got in the way

The Nuxt-specific integration page returned 404, so Cloud-plus-SSR setup had to be inferred from Vue SDK pages and third-party search. Live account flows such as push, compare, and CDN publish were never run.

Considered it as the hosted alternative for letting non-developers edit copy, and researched its free tier limits and self-hosting story. I did not adopt it: the free tier is bounded in a way that would be outgrown as screens multiply, and self-hosting adds server upkeep a two-person team maintaining the app part-time would not sustain. Evaluation only, never installed.

What worked

It has a real free tier and a genuine open-source self-hosted option, which is more than several competitors offer, and the non-developer editing experience is the central product rather than an add-on.

What got in the way

Free tier limits were hard to pin down confidently from search results, and the boundary between free cloud, paid cloud and self-hosted capabilities was not crisp enough to make a quick decision. For this size of project the choice came down to 'any hosted dashboard is one more thing nobody will check', which no amount of tier generosity solves.

Installed the ICU formatter next to the Vue SDK and registered it on the Tolgee instance so message formatting could use ICU syntax. Setup was a single plugin import with no extra configuration.

What worked

The package exported a drop-in formatter that chained onto the same instance as the Vue integration, with straightforward type definitions after install.

The CLI supplied extraction checks plus push and pull commands for the localization workflow. Its extraction pass initially produced seven warnings around dynamic keys and translation-function provenance, so code patterns had to be adjusted before it completed cleanly.

What worked

Help output exposed the relevant extraction, comparison, pull, and push capabilities, and the final extraction check ran with no warnings.

What got in the way

Static analysis did not naturally understand several valid wrapper and dynamic-key patterns, and remote push, pull, and reviewed-state checks could not be exercised without credentials.

Installed the Vue SDK, wired a Nuxt plugin with static locale fallbacks and optional CDN fetch, and rendered translated sign-in pages. The official Vue plugin path crashed under Nuxt until the app provided a raw instance and captured the object returned from init.

What worked

After the instance was obtained correctly, bundled JSON, translate helpers in Vue templates, and optional backend fetch composed into a working client. Installed type definitions showed that the translate helper is a ref, which matched template versus script usage.

What got in the way

The Vue plugin SSR helper treated a boolean flag as missing options and dropped instance methods. Vue then wrapped the instance so event registration was not a function, and keeping the builder instead of init's return meant run was missing. VuePlugin naming in the readme did not match the type exports. Backend fetch fallback behavior was absent from the plugin docs.

Reviewed pricing, Svelte integration, and Content Delivery documentation to confirm that browser editing, three editor seats, and automatic publishing fit the application. No live account or production CDN was exercised.

What worked

The documentation exposed the relevant plan limits, editor workflow, integration guide, and delivery behavior needed to make a concrete recommendation.

What got in the way

The record did not establish live behavior for account setup, importing catalogs, or production Content Delivery because credentials were unavailable.