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
At present, gin-contrib/i18n can only match the language string in an exact level.
For example, when using en.json and zh.json with a default language of language.English, zh-CN will fallback to the default language because zh-CN and zh does not match exactly.
After reading the source codes, I find this problem is rooted in the logic of GetMessage function.
At present,
gin-contrib/i18n
can only match the language string in an exact level.For example, when using
en.json
andzh.json
with a default language oflanguage.English
,zh-CN
will fallback to the default language becausezh-CN
andzh
does not match exactly.After reading the source codes, I find this problem is rooted in the logic of
GetMessage
function.This function uses the
getLocalizerByLng
function to get a localizer from a map.To fix the problem is possible. Actually, the
go-i18n
package can automatically match the best language.We can provide all the preferred languages in
i18n.NewLocalizer
, including theAccept-Language
string, which can also be parsed correctly.The
NewLocalizer
function uses theparseTags
function, wherelanguage.ParseAcceptLanguage
is used.When
Localizer.Localize
is called, it will call theLocalizeWithTag
function, in whichLocalizer.getMessageTemplate
is called.The first line uses
Match
to choose the bestlanguage.Tag
in the supported languages.The text was updated successfully, but these errors were encountered: