[Bug] Some `uniqueName`s don't match up with i18n entries

[Cypheriel]

Describe the bug

Item's such as /Lotus/Types/Recipes/Weapons/WeaponParts/PrimeWyrmCerebrum are missing i18n entries in i18n.json

NodeJS Version

N/A

npm Version

N/A

warframe-items Version

N/A

Access Method

npm Package (Default)

What happened?

When looking at the components of Wyrm Prime, you are given /Lotus/Types/Recipes/Weapons/WeaponParts/PrimeWyrmCerebrum for its cerebrum. However, when looking that uniqueName up in i18n.json, there are zero matches. It does seem that the Public Export provides the correct value under /Lotus/Language/Menu/CraftingComponent_PrimeWyrmCerebrum: "Wyrm Prime Cerebrum". It's worth mentioning that I gathered this information from an unrelated project, however I hope it provides some insight into the issue.

Side note: It would seem that the names for components in general tend to be... too vague. For example, "Cerebrum" as a component name is close to unusable when it comes to internationalization. In this case, it should be "Wyrm Prime Cerebrum", as it would be in-game.

[TobiTenno]

yeah, the problem is you're comparing a language entry for the interface (/Lotus/Language/Menu/CraftingComponent_PrimeWyrmCerebrum) with a component item (/Lotus/Types/Recipes/Weapons/WeaponParts/PrimeWyrmCerebrum). We have no way to mesh these values.

re: "generic" component names, that's on purpose to allow better image coalescing with common component images so we don't accidentally generate thousands of duplicate images.

There's not really anything for us to do here, as they aren't programmatically related (like one of the names isn't combined in the other) apart from the final part of the component item being appended to /Lotus/Language/Menu/CraftingComponent_, which we can't really confirm is universally true to mesh up.

[TobiTenno]

i'll try it out, but definitely reclassing this as an enhancement request

[TobiTenno]

ok, did some analysis, had my llm write up this summary of what i'm thinking for doing to solve this....

Seeking consumer input: component schema + i18n (#617)

Problem: Recipe component uniqueNames (e.g. /Lotus/Types/Recipes/Weapons/WeaponParts/PrimeWyrmCerebrum) are missing from i18n.json because those items are skipped as top-level and only nested under parents. Looking them up by uniqueName fails.

Digital Extremes’ ExportResources already has matching uniqueNames and locale names — we do not need to mesh /Lotus/Language/Menu/CraftingComponent_* keys.

Naming: Component names will stay stripped in all locales (Cerebrum, not Wyrm Prime Cerebrum / Wyrm Prime: Cerebrum) for image coalescing / trade chat. Reconstruct full labels via parent + component.

Size context (approx. current build):

• Category JSON total: ~70 MB
• Nested components arrays: ~46 MB
• ~6012 nested instances vs ~2610 distinct uniqueNames
• Most of the bloat is duplicated drops on shared/repeated parts

---

Option A — Additive (low break)

Keep full nested components[] objects as today.

• Add i18n keys for component uniqueNames (stripped locale names)
• Add parentUniqueName on each nested instance (points at that parent only)

Breaking? Mostly additive. New i18n keys; optional new field.

Downside: No JSON size win.

---

Option B — Centralize components (maintainer preference)

New components catalog (e.g. Components category / map keyed by uniqueName).

Parent components become refs:

"components": [
  {
    "uniqueName": "/Lotus/Types/Recipes/WarframeRecipes/AshChassisComponent",
    "itemCount": 1
  }
]

Central record holds shared fields once (name, description, imageName, drops, ducats, flags, …) plus parentUniqueNames: string[] for reverse lookup.

i18n keyed by component uniqueName with stripped locale names.

Breaking — yes (likely major semver):

• item.components[i].name / .drops / .imageName / etc. without resolving the catalog
• Category / All composition and TypeScript types (Component vs ref)
• Downstream that flattens item.components as full items (APIs, inventory, drop UIs)
• Need a clear rule for nested component-on-component data (refs one level vs recursive)

Win: Large size reduction; clean component → parents via parentUniqueNames.

---

Option C — Hybrid (compat bridge)

Ship B’s catalog + refs, plus either:

• a deprecated expanded components / componentsExpanded for one major, or
• a package helper like resolveComponents(item)

Breaking: Soft during deprecation if helper/dual shape exists; hard when expanded form is removed. Temporary size cost if both shapes ship.

---

If you consume item.components, please comment:

1. Which option works for you (A / B / C)?
2. If B/C: what resolve API would you want?
3. Any hard blockers for a major-version break?