arktype•2mo ago

Error internationalization (i18n)

Hello! Is it possible to translate the errors into other languages? In my previous setup I was using this for such funtionality: https://github.com/aiji42/zod-i18n I saw this issue opened for individual fields, which would really be great: https://github.com/arktypeio/arktype/issues/722 Is this the way for "general" errors? https://github.com/arktypeio/arktype/issues/404

GitHub

GitHub - aiji42/zod-i18n: Useful for translating zod error messages.

Useful for translating zod error messages. Contribute to aiji42/zod-i18n development by creating an account on GitHub.

GitHub

I18N error message customization · Issue #722 · arktypeio/arktype

Ideally any error message should be specifiable as a Record of strings representing locale IDs to the translations in that locale, e.g: const creditCard = type("number", {mustBe: "a ...

GitHub

I18n and error templates · Issue #404 · arktypeio/arktype

Description The current error messages or great at finding the failed validation returned via api, but this could also be harnessed in the frontend. So it would be really useful to be able to speci...

73 Replies

ssalbdivad•2mo ago

This hasn't been addressed internally yet but definitely something I'm interested in adding APIs for now that the rest of error customization is stable Some of the nuances of the sequential approach to building clear, composable errors in English that I created for ArkType may be harder to translate to other languages, but worst case scenario adding a top-level option to replace the whole message should definitely be doable The nice thing about the error message customization setup for English is that you can change individual parts of the message like expect, actual, or how they're composed together or integrated with other context like that path. That way, we can leverage that more granular level of description to write coherent messages even for unions

PIat•2mo ago

Thank you for the insight @ssalbdivad I believe that adding translations is very important for frontends, like in my use case, where the forms should be translated to the user's language of choice.

ssalbdivad•2mo ago

Yeah that makes sense

PIat•2mo ago

And your worst case scenario actually sounds like the best case scenario I would think of 😁

ssalbdivad•2mo ago

Realistically I do want to focus a bit on wrapping up docs and stabilizing the features that are there but this will likely be one of the first things I tackle after. I just want to make sure the API is good

PIat•2mo ago

That's what's done in the Zod library, give or take - instead of the message, a translation key + values are output, which are then passed into the i18n solution of choice Then I'm able to write own translation files for every language

"errors": {
    "invalid_type": "Expected {{expected}}, received {{received}}",
    "invalid_type_received_undefined": "Required",
    "invalid_type_received_null": "Required",
    "invalid_literal": "Invalid literal value, expected {{expected}}",
    "unrecognized_keys": "Unrecognized key(s) in object: {{- keys}}",
    "invalid_union": "Invalid input",
    "invalid_union_discriminator": "Invalid discriminator value. Expected {{- options}}",
    "invalid_enum_value": "Invalid enum value. Expected {{- options}}, received '{{received}}'",
    "invalid_arguments": "Invalid function arguments",
    "invalid_return_type": "Invalid function return type",
    "invalid_date": "Invalid date"
}

"errors": {
    "invalid_type": "Expected {{expected}}, received {{received}}",
    "invalid_type_received_undefined": "Required",
    "invalid_type_received_null": "Required",
    "invalid_literal": "Invalid literal value, expected {{expected}}",
    "unrecognized_keys": "Unrecognized key(s) in object: {{- keys}}",
    "invalid_union": "Invalid input",
    "invalid_union_discriminator": "Invalid discriminator value. Expected {{- options}}",
    "invalid_enum_value": "Invalid enum value. Expected {{- options}}, received '{{received}}'",
    "invalid_arguments": "Invalid function arguments",
    "invalid_return_type": "Invalid function return type",
    "invalid_date": "Invalid date"
}

ssalbdivad•2mo ago

"invalid_union": "Invalid input", This is the problem haha

PIat•2mo ago

Yes, this approach is very naive The whole file, if you're interested

ssalbdivad•2mo ago

I mean it's really complicated to write a good union error though I'm not saying all libraries should handle it I just need to think a bit about the best way to extend the existing approach to multiple languages

PIat•2mo ago

zod.json

ssalbdivad•2mo ago

Feel free to add your thoughts to the open issue so I can reference them when I work on it

PIat•2mo ago

If you are really going into it with i18n in mind, it will really be something else Okay!

ssalbdivad•2mo ago

This is the logic now for the default union error message:

PIat•2mo ago

Many string literals will have to be refactored :/ Is this chainable?

ssalbdivad•2mo ago

Yeah, I'll have to think about how the composition part will work with other languages

Gaming

Programming

Error internationalization (i18n)