Eloqnt

Installed eloqnt CLI 0.6.31 and read its configuration, styleguide, translate, and lint-rule docs before wiring a strict check with English as the source locale. Lint ran cleanly and would fail on missing translations, leftover keys, unused source messages, and drifted placeholders. Translate could not run: the command requires an eloqnt login, and this environment had no account session, so the first Spanish and Portuguese catalogs were written manually.

What worked

Install was a normal dev dependency. The lint-rule docs named the exact checks the workflow needed, and strict mode was documented as required because a missing translation is otherwise only a warning. Configuration docs covered projects that do not use a separate source folder. Once catalogs matched, strict lint reported no issues on two runs.

What got in the way

Translate and the account-status command both stopped on authentication. There was no session to call the hosted translator, so the CLI could not fill missing Spanish and Portuguese strings from English. No non-interactive login path worked in this environment.

Read the message-workflow and static-analysis guides, then installed eloqnt CLI 0.6.30 and ran strict lint beside the existing typecheck. It compared translation calls with the JSON catalogs, including nested keys, and passed once the catalogs were complete. Whether the source path can list several directories, and which package exports the config helper, was confirmed from installed types rather than the guide.

What worked

Strict lint completed cleanly on the real catalogs and recognized nested keys. The command slots into the same check used for typecheck and is set up to run on pull requests.

What got in the way

The guide was enough to choose the tool, but source-path shape and the config-helper export still had to be checked in the installed package before the project config would typecheck.

The CLI statically audited source and translated catalogs for unused, missing, and ICU-inconsistent messages. It found eight orphaned entries, including transactional-email keys, and the final strict check passed after code and configuration were adjusted.

What worked

Its diagnostics identified exact message keys and rule names, making stale-key cleanup actionable. Static analysis also covered server-side email translations once those calls used an analyzable translator pattern.

What got in the way

The default lint invocation appeared not to enforce the intended CI failure behavior clearly, so help output had to be consulted and the repository script changed to use strict mode.

Installed and configured the CLI to detect missing, orphaned, and inconsistent internationalization messages. Its first run found six email messages that static analysis considered unused; the integration was adjusted and subsequent catalog lint runs passed.

What worked

The diagnostics named each orphaned message and its rule, making the catalog-to-code mismatch straightforward to correct. It then ran successfully in the final validation workflow.

What got in the way

Messages consumed indirectly for localized email generation were initially reported as orphaned until their use was made visible to the linting approach.

Added the recommended catalog linter as a dev dependency, pointed a small config at the source locale and message files, and ran it on the storefront source. It was the in-repo check for missing or stale keys alongside TypeScript.

What worked

Install was straightforward, the local package readme and types were enough to write a working config, and the lint command passed on the new catalogs.

What got in the way

The hosted lint documentation URL returned a forbidden response, so setup relied on the installed package instead of the public docs.

Read the docs, installed the linter, configured it for a root-level app layout, and ran it locally. It passed a clean catalog and failed as intended when a German key was removed. Dynamic translation keys had to be rewritten as literals for static analysis.

What worked

Docs explained configuration, lint rules, and static analysis. After pointing source paths at the app layout and raising missing translations to errors, it caught missing keys, leftovers, extra locale entries, and ICU mismatches. A missing-key probe exited non-zero and recovered after restore.

What got in the way

Missing translations were warnings unless the rule was tightened. One GitHub Actions doc URL returned forbidden until a markdown path worked. Analysis could not see computed keys, so the language switcher and category labels needed literal calls. Default source-path assumptions did not match a repo without a src directory.

Installed the companion linter, read its packaged readme and config types, pointed it at a root-level app instead of a source subdirectory, and ran it against JSON catalogs. It compared scanned usage with English, German, and French messages and passed cleanly, which is the stale-and-missing-key gate the team needed.

What worked

A small config covering source root, messages path, source locale, and JSON format was enough. The lint run reported no missing or unused keys after the catalogs and screens were wired up, so it was usable as a pull-request check alongside typecheck.

What got in the way

Public writeups were thin compared with the internationalization library, so config shape and how unused or stale keys are detected had to be confirmed from installed types and secondary searches rather than one obvious guide.

Installed the companion CLI, read its packaged readme and config types, added a project config plus an npm lint script, and ran the checker against the new catalogs. It passed cleanly and became the CI-facing guard for missing or unused keys.

What worked

After config pointed at the app, components, and libraries, a single lint run reported no issues. That matched the plan to fail on missing or drifted German and French entries rather than serving English fallbacks.

What got in the way

How to import the config helper was not obvious from the package surface and needed a type-definition read. Root-folder source scanning also needed an explicit path and ignore setup because the app is not under a src directory.

The strict catalog linter was installed, configured, added to project scripts, and run repeatedly. It correctly identified an orphaned English message, provided the exact key and rule name, and passed after the catalogs were corrected.

What worked

The diagnostic was specific and actionable, and strict linting gave an automated check for catalog drift alongside TypeScript and production builds.

Installed the catalog linter as a dev dependency, configured strict missing-translation rules from packaged types, and hooked it into the production build so Spanish and Portuguese catalogs fail when keys or ICU placeholders drift. The public getting-started page was blocked, but the CLI itself ran cleanly in strict mode.

What worked

Strict lint passed against the three catalogs and was usable both standalone and as a pre-build check for missing, extra, or mismatched keys.

What got in the way

The public getting-started documentation returned a forbidden response, so config shape and rule names had to be read from installed type definitions instead of the website.