Any reason translation registration needs a validator instance? #1077
Replies: 3 comments 2 replies
-
My use case is that I need different rules for the same struct in different parts of my code, so I would need a new |
Beta Was this translation helpful? Give feedback.
-
Hmm I see, |
Beta Was this translation helpful? Give feedback.
-
I created a PR #1079 with a simpler solution to this problem, please see what you think. |
Beta Was this translation helpful? Give feedback.
-
Each translation has a registration function with this signature:
It needs a
*validator.Validate
instance because it calls RegisterTranslation on it, but I can't see why it couldn't just only register them inut.Translator
together withtranslateFunc
, and the validator instance would then fetch this list from it. This would enable creating multipleValidator
instances using the sameTranslator
, which is impossible today as registering translations in each instace overrides the Translator instance and errors out on duplicated translation.For example, we could change the translator registration code to this (current code is commented before the changes):
We would need to modify
Translator.Add
to accept and store a translateFunc, and some function to fetch this list. This translateFunc has no hard binding to a Validator instance, so it should not be a problem.Then we could have a method like
func (v *Validate) RegisterTranslationInstance(trans ut.Translator)
that would just copy the list fromtrans.translations
to its internalv.transTagFunc
to keep the same pattern as today.Beta Was this translation helpful? Give feedback.
All reactions