fix: export internal interpolation options

[ErnestM1234]

Summary

• export the internal InterpolationOptions type from gt-i18n/internal via a bundled-safe alias
• add a patch changeset for gt-i18n

Verification

• pnpm --filter gt-i18n typecheck
• pnpm --filter gt-i18n... build
• pnpm exec oxfmt --check packages/i18n/src/internal.ts .changeset/internal-interpolation-options.md
• pnpm exec oxlint packages/i18n/src/internal.ts
• pnpm build

Greptile Summary

This PR exports the InterpolationOptions type from the gt-i18n/internal entry point, accompanied by a patch changeset, so that consumers of the internal API have access to that type without reaching into private modules.

• A new export type InterpolationOptions = NormalizedLookupOptions<StringFormat> is added to internal.ts, along with two supporting import type statements — however, an identical type alias already exists and is exported from interpolateMessage.ts; re-exporting from that file directly would avoid the duplication.
• The changeset correctly marks the change as a patch for gt-i18n with an accurate description.

Confidence Score: 4/5

The change is a pure type export with no runtime impact; the type itself is correct and structurally matches the existing definition.

The newly added InterpolationOptions alias in internal.ts is an independent redefinition of the same type that already lives in interpolateMessage.ts. While this won't cause any runtime breakage, it creates two canonical locations for the same type that could silently diverge under future edits. Everything else — the changeset scope, the generic instantiation, and the surrounding exports — looks correct.

packages/i18n/src/internal.ts — the duplicate type alias at line 31 is the only item worth revisiting.

Important Files Changed

Filename	Overview
packages/i18n/src/internal.ts	Adds InterpolationOptions type alias and two supporting imports; the alias duplicates an identical definition already exported from interpolateMessage.ts, which could be re-exported directly instead.
.changeset/internal-interpolation-options.md	Standard patch changeset for gt-i18n describing the new type export; content is accurate and correctly scoped.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["@generaltranslation/format/types\n(StringFormat)"] --> B
    C["translation-functions/types/options\n(NormalizedLookupOptions)"] --> B

    B["interpolateMessage.ts\nexport type InterpolationOptions =\nNormalizedLookupOptions<StringFormat>"]

    A --> D
    C --> D

    D["internal.ts\nexport type InterpolationOptions =\nNormalizedLookupOptions<StringFormat>\n⚠ duplicate alias"]

    B -->|"already exports\nInterpolationOptions"| E["gt-i18n/internal\n(public API)"]
    D -->|"also exports\nInterpolationOptions"| E

    style D fill:#fffbe6,stroke:#f0a500
    style B fill:#e6f4ea,stroke:#34a853

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A["@generaltranslation/format/types\n(StringFormat)"] --> B
    C["translation-functions/types/options\n(NormalizedLookupOptions)"] --> B

    B["interpolateMessage.ts\nexport type InterpolationOptions =\nNormalizedLookupOptions<StringFormat>"]

    A --> D
    C --> D

    D["internal.ts\nexport type InterpolationOptions =\nNormalizedLookupOptions<StringFormat>\n⚠ duplicate alias"]

    B -->|"already exports\nInterpolationOptions"| E["gt-i18n/internal\n(public API)"]
    D -->|"also exports\nInterpolationOptions"| E

    style D fill:#fffbe6,stroke:#f0a500
    style B fill:#e6f4ea,stroke:#34a853

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/i18n/src/internal.ts:1-2
**Duplicate type alias instead of re-export**

`InterpolationOptions` is already defined and exported from `./translation-functions/utils/interpolation/interpolateMessage` (line 13 of that file) as `NormalizedLookupOptions<StringFormat>`. Creating a second, independent alias here means the two definitions can drift if the source type ever changes, and it forces two new `import type` statements that serve no other purpose. Using `export type { InterpolationOptions }` from the source file would be bundle-safe (type-only exports carry no runtime weight) and keeps a single canonical definition.

_{Reviews (1): Last reviewed commit: "fix: export internal interpolation optio..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Duplicate type alias instead of re-export

InterpolationOptions is already defined and exported from ./translation-functions/utils/interpolation/interpolateMessage (line 13 of that file) as NormalizedLookupOptions<StringFormat>. Creating a second, independent alias here means the two definitions can drift if the source type ever changes, and it forces two new import type statements that serve no other purpose. Using export type { InterpolationOptions } from the source file would be bundle-safe (type-only exports carry no runtime weight) and keeps a single canonical definition.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/i18n/src/internal.ts
Line: 1-2

Comment:
**Duplicate type alias instead of re-export**

`InterpolationOptions` is already defined and exported from `./translation-functions/utils/interpolation/interpolateMessage` (line 13 of that file) as `NormalizedLookupOptions<StringFormat>`. Creating a second, independent alias here means the two definitions can drift if the source type ever changes, and it forces two new `import type` statements that serve no other purpose. Using `export type { InterpolationOptions }` from the source file would be bundle-safe (type-only exports carry no runtime weight) and keeps a single canonical definition.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!