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

x/text/language: change of behavior for language matcher #24211

LayneChris opened this issue Mar 2, 2018 · 10 comments

x/text/language: change of behavior for language matcher #24211

LayneChris opened this issue Mar 2, 2018 · 10 comments


Copy link

@LayneChris LayneChris commented Mar 2, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?


Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

linux amd64

What did you do?

The package seemed to have changed in the behaviour of language matching with an update a few days ago:

package main

import (


func main() {
    s := []language.Tag{language.MustParse("en"), language.MustParse("fr")}
    p := []language.Tag{language.MustParse("en-US"), language.MustParse("en")}

    l := language.NewMatcher(s)
    ll, _, _ := l.Match(p...)


What did you expect to see?

This used to print "en" but now prints "en-u-rg-uszzzz". This doesn't make sense because I only support "en" and "fr" so why is it returning something else? Switching the order of my preferred languages gives "en".

Is there a rhyme or reason why the change because I cannot understand? Defeats the purpose of a language "matcher" if it is going to return languages that I don't support.

If this is by design what is the best way to get just "en". Parent()? Base()? SomethingElse()?

What did you see instead?

"en-u-rg-uszzzz", a language I do not support.

@bradfitz bradfitz changed the title Change of behavior for language matcher x/text/language: change of behavior for language matcher Mar 2, 2018
@gopherbot gopherbot added this to the Unreleased milestone Mar 2, 2018
Copy link

@bradfitz bradfitz commented Mar 2, 2018

/cc @mpvl

@andybons andybons added the NeedsInvestigation label Mar 13, 2018
Copy link

@basgys basgys commented Mar 14, 2018

This issue seems to occur only when the preferred language contains regional preferences.



  • en
  • en-GB
  • de-CH
  • fr-CH
  • en-US


  • want en expect result en actual result en
  • want fr expect result fr-CH actual result fr-CH
  • want de expect result de-CH actual result de-CH
  • want en-GB expect result en-GB actual result en-GB
  • want fr-CH expect result fr-CH actual result fr-CH
  • want de-CH expect result de-CH actual result de-CH
  • want it expect result en actual result en
  • want it-CH expect result en actual result en-u-rg-chzzzz


This regression was introduced on this commit: golang/text@6008361#diff-c716fa1ccf70cc54ac8b513b999c84eb


if w.RegionID != tt.RegionID && w.RegionID != 0 {
	if w.RegionID != 0 && tt.RegionID != 0 && tt.RegionID.Contains(w.RegionID) {
		tt.RegionID = w.RegionID
	} else if r := w.RegionID.String(); len(r) == 2 {
		// TODO: also filter macro and deprecated.
		tt, _ = tt.SetTypeForKey("rg", strings.ToLower(r)+"zzzz")

Temporary workaround
Rollback to commit 2120f96286c5897163172b6f5ac2fd0921777714 cc @LayneChris

Copy link

@nicksnyder nicksnyder commented Apr 4, 2018

I was just bitten by this today.

Here is a minimal repro (does not repro on

package main

import "fmt"
import ""

func main() {
	m := language.NewMatcher([]language.Tag{language.English})
	tag, i, conf := m.Match(language.AmericanEnglish)
	fmt.Println(tag, i, conf) // en-u-rg-uszzzz 0 Exact

Copy link

@nicksnyder nicksnyder commented Apr 4, 2018

I notice that the documentation says this:

Note that Tag that is returned by Match and MatchString may differ from any of the supported languages, as it may contain carried over settings from the user tags. This may be inconvenient when your application has some additional locale-specific data for your supported languages. Match and MatchString both return the index of the matched supported tag to simplify associating such data with the matched tag.

It seems like the intended behavior is to save the input array passed to the matcher and then use the index returned from Match.

It is annoying that I can't query the input array from the matcher itself though.

Example workaround

package main

import "fmt"
import ""

func main() {
	supported := []language.Tag{language.English}
	m := language.NewMatcher(supported)
	_, i, conf := m.Match(language.AmericanEnglish)
	fmt.Println(supported[i], i, conf) // en 0 Exact

Copy link

@dnx2k dnx2k commented May 30, 2018

My temporary workaround:

langTag, _, _ := languageMatcher.Match(tags...)
langTagString := langTag.String()[0:2]

stapelberg added a commit to stapelberg/debiman that referenced this issue Aug 9, 2018
See golang/go#24211 for more details

This hit us for a zh_CN manpage with precisely one "en" option: the returned tag
is en-u-rg-chzzzz, not en.
Copy link

@chenjie4255 chenjie4255 commented Sep 21, 2018

I was a bit surprised by this when I meet this problem in my production environment ,is that just a mistake? I was really loving golang, but this is really frustrated me, my every beliefs on golang have beed break.

it not something about changing the exists codes or improving my project's unit test, it never be.

Copy link

@schmurfy schmurfy commented Apr 14, 2020

I just got bitten by this, why is it still open after so long ?

Copy link

@dradtke dradtke commented May 4, 2020

This seems like the most straightforward, least-hacky way to get the language out of the tag:

supported := []language.Tag{language.English}
m := language.NewMatcher(supported)
tag, _, _ := m.Match(language.AmericanEnglish)
base, _, _ := tag.Raw()
languageCode := base.ISO3() // eng

playground link

Copy link

@svenwltr svenwltr commented Aug 21, 2020

Experiencing this on a patch update is quite irritating.

We use this as a workaround:

strings.Split(tag.String(), "-")[0]

Copy link

@razor-1 razor-1 commented Apr 4, 2021

Should the community conclude that Match is not going to receive bug fixes?

We have issues like this one going back 3 years, and these:

with no progress

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests