Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n package for zog #26

Closed
Oudwins opened this issue Sep 16, 2024 · 10 comments
Closed

i18n package for zog #26

Oudwins opened this issue Sep 16, 2024 · 10 comments

Comments

@Oudwins
Copy link
Owner

Oudwins commented Sep 16, 2024

The idea is to go one step futher in supporting i18n and have an actual small package dedicated to this. It will have a function that takes a language map and will server default errors based on that map.

Currently it is only planned to support the translation to spanish

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 16, 2024

@cachesdev has agreed to help handle some of the translations!

@cachesdev
Copy link
Contributor

cachesdev commented Sep 16, 2024

I was thinking about this, and there are many ways we can proceed, you can always go with a direct translation where the types are translated. in example, a string will become "cadena" a number will become "numero" and so on, or you could refer only to the types in english, while keeping the message in the target language. the third option is to say "field" or "campo" instead of the type itself, but this assumes validation for a form, zog can be used in more than just form validation.

// translate types Cadena
p.ErrCodeMin:  "la cadena debe contener al menos {{min}} caracter(es)",

// Original type
p.ErrCodeMin:  "string debe contener al menos {{min}} caracter(es)",

// Refer to it as a field
p.ErrCodeMin:  "el campo debe contener al menos {{min}} caracter(es)",

in Latam we usually refer to the translated version of types, not the original english terms. in a conversation it would be normal to talk about "cadenas, booleanos, mapas y listas" so the direct translation has some merit.

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 17, 2024

I think you are right about direct translation being the right approach. Ideally I would like for this errors to be fine to display to non technical users.

The reason field is not being used and instead the type name is being used is because:

  1. That is how zod does it
  2. I don't want the validation messages to only be valid for user input

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 17, 2024

I have the start of a working version for the i18n package. I'll hopefully push it up today and you can take a look at it.

The main idea is:

  1. Have a simple i18n package which has a single function to set the languages you are going to use & their language maps plus the default language
  2. Have sub packages with error maps for each language we want to support. For example zog/i18n/es would be the package for spanish.

This way if you need to support spanish and english you would do something like this:

zi18n.SetLanguagesMap(map[string]conf.LangMap["es": zes.Map, "en": zen.Map,], "en") // default lang = en

Then when you parse:

errs := schema.Parse(data, &dest, z.withCtxValue("lang", "es"))

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 18, 2024

@cachesdev Its ready. You can see the PR at #28

@cachesdev
Copy link
Contributor

that looks good. so by the looks of it a language package will only export a variable Map of type LangMap? do you want me to open a PR with the zes package on that branch?

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 18, 2024

Yes. That would be amazing! @cachesdev

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 18, 2024

I also still need to add documentation and move the en lang map before mergin that PR

@cachesdev
Copy link
Contributor

@Oudwins opened the PR

@Oudwins
Copy link
Owner Author

Oudwins commented Sep 19, 2024

RESOLVED IN #28

@Oudwins Oudwins closed this as completed Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants