eloqnt review

Context enrichment

Your messages hold a set of strings, but they typically lack context on how they’re used:

{
  "7HMn4v": "Invite to your team space",
  ...
}

Without additional information, it’s hard to tell:

1. Where this string is used
2. What kind of UI component it’s used for
3. What "your team space" refers to
4. If a term like "team space" matches the rest of your app
5. If it matches the typographic guidelines of your app

If you have srcPath configured, the CLI will analyze your code and extract a simplified source outline that keeps the relevant parts around each string:

⋮
│ export default function MembersHeader() {
│   const t = useExtracted();
│   return (
│     <header>
⋮
│       <Button>
█         {t('Invite to your team space')}
│       </Button>
⋮

This provides clear answers to the first three questions raised above:

1. It’s used in a component called MembersHeader
2. It’s the label of a button
3. "Your team space" is the workspace this page belongs to

Styleguides

Next, all applicable styleguides are attached to the request:

• Your global styleguide, defining the terminology of your project
• The styleguide of your source locale, holding explicit rules for your source strings

...

## Terminology

- "workspace": The place where a team keeps its projects

...

...

## Capitalization

- Menu items, button labels, and alert titles use Title Case.
- All other UI text uses sentence case.

With this, we can answer the remaining questions from above:

4. The term "workspace" should be used instead
5. As it’s a button label, it should be written in Title Case

It’s recommended to restrict yourself to mechanical rules in the styleguide of your source locale, like typography and capitalization. Instructions about tone could cause your source strings to be rewritten unexpectedly.

Review

With all context now available, the following is passed to an LLM:

1. Your source strings
2. Source outlines
3. Styleguides
4. General guidelines on what a review may change

The LLM is asked to only fix objective errors:

1. Are there misspellings or typos?
2. Are there grammatical errors?
3. Does a string deviate from a styleguide term?

Since the UI component is available as context, your styleguide can scope certain rules to only affect a specific set of use cases.

Depending on your plan, the actual review work either happens on our hosted backend or is delegated to your own model.

Post-checks

Once the LLM returns, every suggested fix has to pass various quality checks, like:

1. Does the fix actually change the string?
2. Are there syntactical errors?
3. Do arguments like {name} still match the original?

If a fix doesn’t meet the bar yet, then the review step is retried with the findings attached, and with increased reasoning effort. A fix that still fails is discarded, and your string stays as it is.

Persistence

Finally, the fixes are written to your source messages:

 {
-  "7HMn4v": "Invite to your team space",
+  "XnhtPl": "Invite to Your Workspace",
   ...
 }

If you’re writing your strings inline with useExtracted from next-intl and have srcPath configured, then the call site in your code is fixed too:

 <Button>
-  {t('Invite to your team space')}
+  {t('Invite to Your Workspace')}
 </Button>

If a fixed string already had translations, they’re removed as stale and the next eloqnt translate fills them back in.