GNOME Bugzilla – Bug 710939
Release Notes with content negociation failure
Last modified: 2018-09-24 10:34:47 UTC
Hello Folks, As sayed in gnome-i18n Mailing List, the Release Notes are not showing properly the images for local versions. It affects every language team that had translated the screen images to their locale versions, like for the Brazilian Portuguese (pt_BR) and German (de) teams. According to Andre Klapper wrote that: "Looks like figures/foo.png instead of figures/foo.png.pt_BR is shown." He also suggested to open a bug report. So, please, may someone inspect it again? Additional resources: [1 - Release notes in Brazilian Portuguese] http://library.gnome.org/misc/release-notes/3.10/index.html.pt_BR [2 - Images on Damned Lies] https://l10n.gnome.org/module/release-notes/help/gnome-3-10/pt_BR/images/ Thanks a lot Enrico Nicoletto.
I can succesfully see all the images on both http://library.gnome.org/misc/release-notes/3.10/index.html.pt_BR and http://library.gnome.org/misc/release-notes/3.10/index.html.de, can you explain me what's the problem?
Created attachment 258251 [details] Screenshot taken of Chromium accessing release notes.
Accessing the pt_BR URL using Chromium or Firefox will display original (english) images and translated text, while accessing it with Epiphany will show everything correctly translated (including the images) -- just now I figured out this last part.
I had it working with Firefox as well with pt_BR or DE as being the only language "installed" on the browser. Also the http headers seems fine. If I just add english on the available languages it fallbacks to english, I feel because of the apache's LanguagePriority list that has 'en' as the favorite language when multiple langs are available on the client. Can you please check it out on Firefox yourself as well? the steps are: preferences --> content --> select the preferred language --> de or pt_BR (make sure english is not on the list at all) The HTTP headers for the wayland.png file: HTTP/1.1 304 Not Modified Date: Sun, 27 Oct 2013 23:18:45 GMT Server: Apache/2.2.15 (Red Hat) Connection: close Etag: "44f052-891f0-4e9ba912ff453;4e73a06910943" Content-Location: status-menu.png.de Vary: negotiate,accept-language,Cookie
Or just make the 'pt_BR' or 'de' entries being the first to appear on the list, and 'en' being the second or third.
Nice. Removing English entries from Firefox's languages list, and therefore leaving only 'pt_BR' and 'pt' in the list, made 'pt_BR' work just fine. However, accessing 'de' page (with only pt_BR and pt listed) displayed german text with portuguese imagens -- not exactly good. The preference order of languages set in my Firefox was: pt_BR, pt, en_US, en. So, leaving en_US or en in the list doesn't seem to work.
Theoretically you should leave on the list only the preferred language for your browser, if your language won't be available on a specific website the browser will just fallback to english on its own.
Totally agree with you. But, in my case, I didn't set it on purpose: it came in the packages of my distribution (archlinux). And if this happen to me, it will most likely happen with others. Enrico, for example, doesn't use same distribution as me and notice the this issue as well.
Yes, as said this is not a real bug, every user should set its own preferred language on the browser used, otherwise apache will automatically follow the list it has specified on httpd.conf which sees 'en' as being the first matching entry. The list it currently follows is: LanguagePriority en ca cs da de el eo es et fr he hr hu it ja ko ltz nl nn no pl pt pt-BR ru sv tr zh-CN zh-TW uk eu af sq be@latn
Andrea, this solution appears to be good for technical users but and for non technical users like Bloggers, Journalists, and other audiences that could have interest in reading the Release Notes but without technical experience in those issues? I don´t have enough technical knowledge in this issue, despite I think Release Notes have a better design compared to the previous versions, I strongly believe that a a workaround for this issue is still necessary.
Honestly speaking there's not much we can do, each user has a specific language list on the browser and each language gets a major or minor priority assigned by the user. (that's probably done automatically in Firefox with the preferred system language, at least on Fedora) If the user didn't setup its own preferred language in the list, the web server will just honor the list it has specified on httpd.conf, thus it'll fallback to 'en' by default. It should be up to the user to specify that setting given things are configured properly on our end. The web server requires the following headers to be sent to process the request correctly: Accept-Language: de,en;q=0.7,it;q=0.3 This HTTP header tells apache that the preferred lang is 'de' at first (which has a major priority on the list) then 'en' (with the same priority) and 'it' follows. What happens here is 'de' gets selected because the requested resources are available on the web server, which then serves them correctly. If the 'de' resources weren't found, the web server would have fallback to 'en'. What we can probably do is adding a little header on the top of the page (like the one used by many websites for the cookie's policy agreement) explaining this and pointing to a very short howto on our wikis.
Well, this idea is very good to alert the unaware users. So, please, add in this little header on the top of the page pointing to a howto for the most popular browsers, like firefox, chromium, opera... Thanks a lot, Enrico.
fwiw that page is already written, https://help.gnome.org/about/langinfo.html but I don't see how Andrea envisioned to display that banner at the top.
Fred, mine was just a suggestion to help users understand how this works, I maintain the infrastructure that runs help.gnome.org, not help.gnome.org itself, so that's definitely your call. Nothing changed on the web server's configuration in this regard since some years, so I'm wondering why this came up so late without anyone noticing / asking before how to properly setup their browsers for properly showing the preferred and desired language.
Frederic, thanks for the URL. Please notice it states "Generally, you should include all languages you can read in preferred language, ordered by preference. It is good idea to include English ('en') as last item in your list, to use it as a fallback language". That was exaclty my case: my browsers came (installed from distro package this way; no custom setting, just a language pack) with 'en' as fallback language, with 'pt_BR' as preferred. Still images won't appear as expected, unless 'en' is removed as I did for Firefox. I don't know why we didn't see it before - maybe we didn't have time to translate the images in previous versions -, but if we are having this issue even with pt_BR as preferred language, I suppose that users of other languages will notice the same thing.
Created attachment 258291 [details] Chromium language list - pt_BR as preferred
The translated index.html pages should reference the translated images. Not rely on this content negotiation. Since a few GNOME releases we use that new documentation format instead of whatever we had before. Maybe that change resulted in relying more on content negotiation.
This bug report is kinda old, but it is still an issue: the documentation in developer.gnome.org and help.gnome.org (including Release Notes) is still showing up as Portuguese from Portugal (pt) when Brazilian Portuguese (pt_BR) is expected. I don't know how is the web server configuration neither know what is the web service application, but I wonder if adding something like: AddLanguage pt-br .pt_BR could solve the issue. This is an Apache configuration that translates the requested content to the proper extension, which I learned to solve the content negotiation for www.po4a.org -- maybe it works for developer.gnome.org and help.gnome.org as well? Could someone with admin access check the possibility of translating "pt-br" request to file extension ".pt_BR" on GNOME servers?
For the record, here is the fix in po4a website: https://github.com/mquinson/po4a-website/pull/9
Rafael, committed and pushed [1], would you mind testing now? Looks good to me: ➜ ~ curl -iI -H 'Accept-Language: pt-BR' https://help.gnome.org/misc/release-notes/3.18/ HTTP/1.1 200 OK Date: Wed, 01 Aug 2018 18:17:59 GMT Server: Apache/2.2.15 (Red Hat) Content-Location: index.html.pt_BR Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Sun, 03 Apr 2016 12:13:23 GMT ETag: "24c7c-106b5-52f9389e404e8" Accept-Ranges: bytes Content-Length: 67253 Content-Type: text/html; charset=UTF-8 Content-Language: pt_br Connection: close [1] https://infrastructure.gnome.org/browse/puppet/commit/?id=3b70f84
It is indeed working for me (both from curl and the browser). The only problem now is that pages translated to both 'pt' and 'pt_BR' still shows up as 'pt', even though only 'pt_BR' is configured in my browser. (e.g. https://help.gnome.org/) This is probably a browser behavior: I confirmed that in Chromium, Firefox and GNOME Web, but it doesn't happen for curl with the '-H' flag. Can we try putting 'pt_BR' before 'pt' in the AddLanguage block? I think it might influence the result for these browsers, without problem for 'pt'.
Rafael, the language priority is as follows: LanguagePriority en ca cs da de el eo es et fr he hr hu it ja ko ltz nl nn no pl pt pt-BR ru sv tr zh-CN zh-TW uk eu af sq be@latn What's weird is that your browser doesn't come with both languages configured but still you're seeing a pt-translated web page, an example: ➜ curl -iI -H 'Accept-Language: pt;q=0.7,pt_BR;q=0.7' https://help.gnome.org HTTP/1.1 200 OK Date: Wed, 01 Aug 2018 19:00:09 GMT Server: Apache/2.2.15 (Red Hat) Content-Location: index.html.pt Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Wed, 18 Jul 2018 02:05:14 GMT ETag: "4404a5-1cff-5713c7e4b3be2" Accept-Ranges: bytes Content-Length: 7423 Content-Type: text/html; charset=UTF-8 Content-Language: pt Connection: close This happens due to the preference being a tie and thus selecting pt. I'd say that due to the fact Brazil has definitely an higher amount of inhabitants we should probably prefer pt-BR instead of pt itself. Do you agree? :-) ➜ curl -iI -H 'Accept-Language: pt;q=0.7,pt_BR;q=0.9' https://help.gnome.org HTTP/1.1 200 OK Date: Wed, 01 Aug 2018 19:00:06 GMT Server: Apache/2.2.15 (Red Hat) Content-Location: index.html.pt_BR Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Wed, 18 Jul 2018 02:05:14 GMT ETag: "4404a6-1d62-5713c7e52f472" Accept-Ranges: bytes Content-Length: 7522 Content-Type: text/html; charset=UTF-8 Content-Language: pt_br Connection: close With an higher preference instead we get the correct value.
Maybe the web browser gets satisfied with the language code ('pt') without the variant ('_BR') too, if no different weight is set. Based on the output you posted above, please notice how the result is the same ('pt' gets priority), even though I swapped the lang codes but keeping the same preference: curl -iI -H 'Accept-Language: pt_BR;q=0.7,pt;q=0.7' https://help.gnome.org HTTP/1.1 200 OK Date: Wed, 01 Aug 2018 19:41:02 GMT Server: Apache/2.2.15 (Red Hat) Content-Location: index.html.pt Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Wed, 18 Jul 2018 02:05:14 GMT ETag: "4404a5-1cff-5713c7e4b3be2" Accept-Ranges: bytes Content-Length: 7423 Content-Type: text/html; charset=UTF-8 Content-Language: pt Connection: close Looks good to me to give the preference to pt_BR, as I assume it won't impact 'pt' users ('pt' != 'pt_BR', so 'pt' still hit 'pt'). I can test that, after you apply.
The example you posted is expected to return pt as the priority matches. Just applied the change, please give it a try, thanks!
Didn't work... I notice my browser is sending 'pt_BR'. Maybe 'pt_BR', instead of 'pt-BR', should be listed in LanguagePriority ?
$ curl -iI -H 'Accept-Language: pt;q=0.7,pt-BR;q=0.9' https://help.gnome.org HTTP/1.1 200 OK Date: Wed, 01 Aug 2018 20:26:04 GMT Server: Apache/2.2.15 (Red Hat) Content-Location: index.html.pt Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Wed, 18 Jul 2018 02:05:14 GMT ETag: "4404a5-1cff-5713c7e4b3be2" Accept-Ranges: bytes Content-Length: 7423 Content-Type: text/html; charset=UTF-8 Content-Language: pt Connection: close
pt_BR (which is what your browser is sending) is correct as per above example: curl -iI -H 'Accept-Language: pt;q=0.7,pt_BR;q=0.9' https://help.gnome.org HTTP/1.1 200 OK Date: Wed, 01 Aug 2018 21:13:59 GMT Server: Apache/2.2.15 (Red Hat) Content-Location: index.html.pt_BR Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Wed, 18 Jul 2018 02:05:14 GMT ETag: "4404a6-1d62-5713c7e52f472" Accept-Ranges: bytes Content-Length: 7522 Content-Type: text/html; charset=UTF-8 Content-Language: pt_br Connection: close
My intention with my example was to suggest the following change to the config file (I used [...] to abbreviate the line text): - LanguagePriority [...] no pl pt-BR pt ru [...] + LanguagePriority [...] no pl pt_BR pt ru [...] or: + LanguagePriority [...] no pl pt-BR pt_BR pt ru [...] (I'm not an Apache expert, so my suggestion could be incorrect; just trying)
Nope, that won't work as I guess it expects an RFC compliant language code (pt-BR in this case).
Well, right now I don't other ideas on what is causing it, but browsers are still giving priority to pt over pt_BR.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/Infrastructure/Websites/issues/128.