flux-pr-5187
Zod (TypeScript) · W2 · GPT-5.3 Codex
Tests failed. 0/1 commands passed. Strength: weak.
npx vitest run packages/zod/src/v4/core/tests/locales/es.test.ts -t "Spanish\ locale\ \-\ type\ name\ translations\ in\ too_small\ errors|Spanish\ locale\ \-\ type\ name\ translations\ in\ too_big\ errors|Spanish\ locale\ \-\ type\ name\ translations\ in\ invalid_type\ errors|Spanish\ locale\ \-\ fallback\ for\ unknown\ type\ names|Spanish\ locale\ \-\ other\ error\ cases"Partial score: 0/1
Trajectory
unknown · partial order onlyCanonical trajectory missing; showing coarse derived order only.
Quality
Equivalence Reasoning
behavioral
The patch applies `getTypeName(...)` in the right error branches, but the Spanish type map is incomplete/inconsistent with the intended fix: some type labels can still surface as raw English identifiers (e.g. `bigint` is left as `bigint`, and keys like `enum`, `union`, `literal`, `any` are not mapped). So it does not fully achieve consistent Spanish type-name translation across the targeted messages.
Code Review
The patch moves logic in the right direction but likely does not fully satisfy the task: type-name localization remains inconsistent/incomplete in the new map, so user-facing Spanish errors can still contain raw or non-target labels.
The new `TypeNames` map leaves some key labels untranslated or inconsistent (for example `bigint: "bigint"`) and omits several common type keys, so messages can still surface raw/non-Spanish type names despite the new mapping calls.
`invalid_type` now calls `getTypeName(parsedType(issue.input))`, but `parsedType` still emits localized/raw labels for some branches (e.g. number/array/null) while others emit canonical JS type strings; this mixed model can produce inconsistent translations and misses the intended uniform mapping behavior.