Ylc991, Thanks for the report!
My verbose notes so far; I need to (finally!) set up a local build of the Web site first.
ylc991 写道：
Hello! My webbrowser has set ‘Accept-Language’ to 'zh-CN,zh' by default, and https://guix.gnu.org returns 404.
Indeed, handling of zh-CN specifically is broken. :-( --8<---------------cut here---------------start------------->8--- ~ λ curl -LI -H 'Accept-Language: zh-cn' https://guix.gnu.org HTTP/1.1 404 Not Found [...] --8<---------------cut here---------------end--------------->8---This is because our nginx configuration (maintenance/hydra/nginx/berlin.scm) does:
--8<---------------cut here---------------start------------->8--- set_from_accept_language $lang en de es fr zh-CN; [...] try_files $uri /$lang/$uri /$lang/$uri/index.html =404; --8<---------------cut here---------------end--------------->8--- i.e., it looks in /srv/guix.gnu.org/zh-CN, but our website uses... --8<---------------cut here---------------start------------->8--- nckx@berlin ~$ ls -d /srv/guix.gnu.org/zh* /srv/guix.gnu.org/zh-cn/ --8<---------------cut here---------------end--------------->8---...lowercase. This questionable choice comes from artwork/po/ietf-tags.scm:
--8<---------------cut here---------------start------------->8---;;; This file contains an association list for each translation from ;;; the locale to an IETF language tag to be used in the URL path of ;;; translated pages. The language tag results from the translation
;;; team<E2><80><99>s language code from;;; <https://translationproject.org/team/index.html>. The underscore ;;; in the team<E2><80><99>s code is replaced by a hyphen. For example, az would ;;; be used for the Azerbaijani language (not az-Latn) and zh-CN would
;;; be used for mainland Chinese (not zh-Hans-CN)
([...]
("zh_CN" . "zh-cn"))
--8<---------------cut here---------------end--------------->8---
Questionable only because, while a lowercase region is technically
valid, it's so rare that it's likely to cause problems -- as we
found out.
I have tested with curl, 'zh-CN,zh', 'zh-CN', [is 404]
These are valid, so the nginx accept-language module accepts them, but then looks for a subdirectory that doesn't exist and returns 404.
'zh-cn' is 404
This is valid, but since we configure the accept-language module to use ‘zh-CN’ it normalises $lang to the latter. Which is good, but it causes the same 404 as above.
'zh_CN' is 200.
This is bogus (‘_’ is not valid), hence ignored, and so the site falls back to English 200.
'zh' [is 200]
Valid but the accept-language module is not clever; we need to add an explicit 'zh' entry for that to work:
--8<---------------cut here---------------start------------->8--- set_from_accept_language $lang en de es fr zh-CN zh en; --8<---------------cut here---------------end--------------->8---I expect that adding it and changing ietf-tags.scm to use "zh-CN" will fix both 404s, but need to check that it doesn't break anything else.
The other untested solution is using lowercase --8<---------------cut here---------------start------------->8--- set_from_accept_language $lang en de es fr zh-cn zh en; --8<---------------cut here---------------end--------------->8---but I--assuming that even works--'m not fond of making the unconventional the norm.
Kind regards, T G-R
signature.asc
Description: PGP signature
