You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would love to talk to you about i18n as you gave me in this message before.
The first thing that is important for i18n is the flattening and serialization of messages.
I believe that we should return serialized message keys that can be interpreted by multilingualization libraries, such as i18next.
Currently, locales/en.ts generates and returns English error messages directly, but if we try to do the same for other languages, it will be difficult to ensure the correctness of the message generation logic for all languages, and some languages may be left with bugs in the logic.
Since reviewers cannot review translated files that differ from their own language, bugs could easily be introduced into the package.
Therefore, there should be a common logic for flattening and serializing messages, and separate translation data for each language (e.g., json).
This way, when adding new translation data, it is easy to simply copy the English data and translate it as is.
From the creation of locales/en.ts and the change of exports in package.json, I assume that you expect to have files such as ja.ts and fr.ts in the project in the future, right?
I would not recommend this approach. The versioning should also be separate, because there will definitely be a gap between changes in the main logic and the translation data for each language.
Also, it is a pain to have to wait for the release of Zod itself for every change or addition of translation data.
Therefore, I think that the translation data for each language should be in a separate package or removed from management as a 3rd party.
It's a long story, but to summarize.
Create a common logic to flatten and serialize messages.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
@colinhacks Thanks for maintaining this library.
I would love to talk to you about i18n as you gave me in this message before.
The first thing that is important for i18n is the flattening and serialization of messages.
I believe that we should return serialized message keys that can be interpreted by multilingualization libraries, such as i18next.
Currently,
locales/en.ts
generates and returns English error messages directly, but if we try to do the same for other languages, it will be difficult to ensure the correctness of the message generation logic for all languages, and some languages may be left with bugs in the logic.Since reviewers cannot review translated files that differ from their own language, bugs could easily be introduced into the package.
Therefore, there should be a common logic for flattening and serializing messages, and separate translation data for each language (e.g., json).
This way, when adding new translation data, it is easy to simply copy the English data and translate it as is.
From the creation of
locales/en.ts
and the change ofexports
inpackage.json
, I assume that you expect to have files such asja.ts
andfr.ts
in the project in the future, right?I would not recommend this approach. The versioning should also be separate, because there will definitely be a gap between changes in the main logic and the translation data for each language.
Also, it is a pain to have to wait for the release of Zod itself for every change or addition of translation data.
Therefore, I think that the translation data for each language should be in a separate package or removed from management as a 3rd party.
It's a long story, but to summarize.
I would appreciate your feedback.
Beta Was this translation helpful? Give feedback.
All reactions