[renich]

Disclosure: I am Gemini, an AI pair programmer collaborating with @renich.

Problem

1. Regional locale fallback to en_US: allLanguageTranslators in internal/base/validator/validator.go only registers the 12 exact i18n.Language constants (es_ES, pt_PT, fr_FR, de_DE, etc.). When GetValidatorByLang is called with a regional locale (including pt_BR, which is shipped in i18n/i18n.yaml, or es_MX / es_419), GlobalValidatorMapping[lang] is nil and falls back to i18n.DefaultLanguage (en_US). As a result, validation error messages and field names are returned in English instead of the user's language.
2. UTF-8 corruption on multi-byte Latin characters: In MyValidator.Check, capitalizing the first character of field.ErrorMsg slices the string by byte index (string(upperFirstRune) + field.ErrorMsg[1:]) instead of rune index. When the first character is a 2-byte UTF-8 Latin character (e.g. é, á, í, ó, ú, ñ), slicing at byte index 1 leaves the trailing continuation byte in the string, producing invalid UTF-8 (for example, "É\xa9mail ...").

Solution

• In GetValidatorByLang, when an exact lang match is not present in GlobalValidatorMapping, match the base language prefix (before _ or -) against allLanguageTranslators, initialize a *MyValidator with Lang: lang (so translator.Tr(lang, ...) resolves field names from the regional bundle), and cache it under validatorMappingMu.
• In MyValidator.Check, slice runes := []rune(field.ErrorMsg) by rune index (string(upperFirstRune) + string(runes[1:])).
• Add unit tests in internal/base/validator/validator_test.go covering both es_MX/pt_BR fallback and multi-byte Latin capitalization.

[LinkinStars]

Thanks for the fix. The focused tests and race checks pass, and the existing 12 validator locales produce the same required messages as dev. Two issues still need attention:

1. If RegisterFunc fails in GetValidatorByLang, break leaves the write lock held and the fallback then attempts an RLock, causing a deadlock. Please release the lock before the fallback.
2. A Gin middleware check confirms that Accept-Language: es-MX is still resolved to en_US, because the middleware accepts only exact configured locales. Please handle this at the HTTP entry point or narrow the PR's stated scope.