It seems that gettext.install() uses environment variables such as LANGUAGE, to find out which language it should use to find the translation file.

This means that any local settings done by setlocale() previoulsy are ignored.

I don't think it's the case with the C implementation.

I tested a small C program and found that setlocale takes precedence for LC_ALL, LC_MESSAGES, and LANG but not for LANGUAGE.

int main(int argc, char **argv) {
    char *message1;

//setlocale (LC_ALL, "");
setlocale (LC_ALL, "pt_BR.utf-8");
bindtextdomain ("testc", "/srv/python/cpython/tmp");
textdomain ("testc");

    message1 = gettext("lemon");
    printf("%s\n", message1);
    return 0;
}

$ LC_ALL=es_MX.utf-8 LANGUAGE= LC_MESSAGES=es_MX.utf-8 LANG=es_MX.utf-8 ./test
limão

$ LANGUAGE=es_MX  LANG=es_MX.utf-8 ./test
limón

So this could be considered a bug in the stdlib's gettext. If we fix it, we'll need to make sure that we continue to honor LANGUAGE, though.

• locale.setlocale calls _setlocale which sets the variable for the process
• gettext.find checks the environment variables: LANG, LANGUAGES, LC_ALL, LC_MESSAGES by os.environ.get()

gettext.find should be modified to fallback to locale.getlocale() which checks the variable for the python process.

cc @tomasr8

I think it makes sense to align our gettext implementation with C, that is, let the result of locale.getlocale override all the environment variables except for LANGUAGE.

In any case, this part of gettext has no dedicated tests. I have a patch ready which tests gettext._expand_lang but more tests will be needed also for gettext.find. Once there is sufficient coverage we can look into fixing this

Testing will not be too simple, environment variables are not something we can really control.

I don't think it'll be that bad, we have EnvironmentVarGuard for that :)

Can I write some tests for find() or do you already have some ready?

Can I write some tests for find() or do you already have some ready?

Feel free! I will open a PR for _expand_lang but I haven't started on find yet. I opened #130655 for it