The newly added "Release Notes" button/link feature is a welcome addition, however on my simplified Chinese Windows 10 system with simplified Chinese LO interface, it opens https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.3&LOlocale=zh in web browser, which then redirects to the English release notes, even though the simplified Chinese RN exists at https://wiki.documentfoundation.org/ReleaseNotes/6.3/zh-cn . It would be nice if the "Release Notes" button/link can go to the localized RN wiki page when it exists. About LO information: 版本: 6.3.1.2 (x64) Build ID: b79626edf0065ac373bd1df5c28bd630b4424273 CPU 线程: 2; 操作系统: Windows 10.0; UI 渲染: GL; VCL: win; 区域语言: zh-CN (zh_CN); UI 语言: zh-CN Calc: threaded
Should this be fixed from website? or LibreOffice itself? https://opengrok.libreoffice.org/xref/core/cui/source/dialogs/about.cxx?r=28fc9860#116 https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/appserv.cxx?r=94d6fa11#589
Is it happening because the wiki page is not translated ?
(In reply to Xisco Faulí from comment #2) > Is it happening because the wiki page is not translated ? I doubt it, because the handcrafted URL https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.3&LOlocale=zh-cn redirects to the simplified Chinese page correctly. The problem is more likely that LO only uses two-letter locale codes for these URLs. I suspect that Brazilian users (pt-BR) are also affected by this bug.
Code is here https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/appserv.cxx?r=97bcd0e4#585 and of course we could go with BCP47 but run into trouble for other languages then.
(In reply to Heiko Tietze from comment #4) > and of course we could go with BCP47 but run into trouble > for other languages then. Indeed. It's the decade-old problem of people in different locales prefer different fallback orders (e.g. en-GB users are perfectly happy to read en-US if en-GB is not available, while zh-TW users probably would rather read English than zh-CN). Unfortunately, I have no better idea than hard-coding every special case that needs full BCP47 notation.
The problem with code vs. BCP47 was mentioned when the links were added to the hub… It can now route BCP47 codes specified as LOlocale parameters, so please update the code accordingly. Right now there are release notes for pt-BR and zh-CN, but not for zh-TW (nor zh) nor de-AT (but de). $ uri="https://hub.libreoffice.org/ReleaseNotes" $ curl -sw "%{url_effective}\\t%{http_code} %{redirect_url}\\n" \ -o/dev/null "$uri?LOvers=6.3&LOlocale=pt-BR" \ -o/dev/null "$uri?LOvers=6.3&LOlocale=pt" \ -o/dev/null "$uri?LOvers=6.3&LOlocale=zh-CN" \ -o/dev/null "$uri?LOvers=6.3&LOlocale=zh-TW" \ -o/dev/null "$uri?LOvers=6.3&LOlocale=de-AT" https://hub.libreoffice.org/ReleaseNotes?LOvers=6.3&LOlocale=pt-BR 302 https://wiki.documentfoundation.org/ReleaseNotes/6.3/pt-br https://hub.libreoffice.org/ReleaseNotes?LOvers=6.3&LOlocale=pt 302 https://wiki.documentfoundation.org/ReleaseNotes/6.3 https://hub.libreoffice.org/ReleaseNotes?LOvers=6.3&LOlocale=zh-CN 302 https://wiki.documentfoundation.org/ReleaseNotes/6.3/zh-cn https://hub.libreoffice.org/ReleaseNotes?LOvers=6.3&LOlocale=zh-TW 302 https://wiki.documentfoundation.org/ReleaseNotes/6.3 https://hub.libreoffice.org/ReleaseNotes?LOvers=6.3&LOlocale=de-AT 302 https://wiki.documentfoundation.org/ReleaseNotes/6.3/de It's a bit slower two 2 internal lookups are done instead of one (first to zh-TW, then to zh if the former is 404). Might be better to redirect LOlocale=pt to pt-br rather than the English page, but no way we can maintain a mapping with preferred fallback and coordinate with translators when a new translation is added.
(In reply to Guilhem Moulin from comment #6) > It's a bit slower two 2 internal lookups are done instead of one (first to > zh-TW, then to zh if the former is 404). The performance issue should be resolved now: instead of issuing n HTTP subrequests until a 200 code is found, the now hub issues a single API call and finds what it needs in the JSON-encoded payload. In practice that significantly reduces the latency.
(In reply to Guilhem Moulin from comment #6) > please update the code accordingly... Done, works like a charm. But the top menu template has no English localization while localized pages do have. Likely a topic for someone else, I guess. https://wiki.documentfoundation.org/ReleaseNotes/6.4/en (.../en is not the same as ../)
(In reply to Heiko Tietze from comment #8) > (In reply to Guilhem Moulin from comment #6) > > please update the code accordingly... > > Done, works like a charm. But the top menu template has no English > localization while localized pages do have. Likely a topic for someone else, > I guess. > > https://wiki.documentfoundation.org/ReleaseNotes/6.4/en > (.../en is not the same as ../) It's not a menu template, it is the languages menu generated by the Translate extension. If you view the /en page, it shows the English language version without the translate tags in the source. What is the problem/topic exactly?
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/787647b488d02be2acbbad4fa7873508dcb926c2 Resolves tdf#127401 - Release notes / What's new not localized It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Buovjaga from comment #9) > What is the problem/topic exactly? No navigation menu for /en.
(In reply to Heiko Tietze from comment #11) > (In reply to Buovjaga from comment #9) > > What is the problem/topic exactly? > > No navigation menu for /en. /en is only for the cases, when you want to go and copy content from its source that is without the translate tags. Users should never navigate there nor be sent there by any hub.
(In reply to Buovjaga from comment #12) > Users should never […] be sent there by any hub. It's been the case since that hub entry was added on May 15 this year. Changed it so LOlocale=en, LOlocale=en-US etc. are all ignored. The location URL becomes https://wiki.documentfoundation.org/ReleaseNotes/$LOvers (with as before a fallback to https://wiki.documentfoundation.org/ReleaseNotes when that page doesn't exist). $ curl -sw "%{redirect_url}\\n" \ -o/dev/null "https://hub.libreoffice.org/ReleaseNotes?LOvers=6.4&LOlocale=en-US" \ -o/dev/null "https://hub.libreoffice.org/ReleaseNotes?LOvers=6.4&LOlocale=en" \ -o/dev/null "https://hub.libreoffice.org/ReleaseNotes?LOvers=1.0&LOlocale=en" https://wiki.documentfoundation.org/ReleaseNotes/6.4 https://wiki.documentfoundation.org/ReleaseNotes/6.4 https://wiki.documentfoundation.org/ReleaseNotes I hope we won't further clutter the logic here, that hub entry is already the more complex we have, and by far :-(
(In reply to Guilhem Moulin from comment #13) > I hope we won't further clutter the logic... /sign!
I can confirm this bug is fixed in 6.4.0 alpha1. Thanks Heiko and Guilhem!
Created attachment 161403 [details] mouse-over tooltip showing wrong URL in 7.0.0 beta1 This bug is back now for me, both with 6.4.4 and 7.0.0 beta1. I've attached a screenshot showing the wrong URL (LOLocale=zh) with 7.0.0 beta1 on Windows 10: Version: 7.0.0.0.beta1 (x64) Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c CPU 线程: 2; 操作系统: Windows 10.0 Build 18363; 用户界面渲染: Skia/点阵; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded I'll refrain from REOPENing it until I can get another Chinese user to reproduce.
Asked in a Chinese user chat group and got another user to reproduce with 6.4.3 on Windows.
Please check which of the following links fail with zh instead of zh-cn: Help > User Guides Help > Get Help Online Help > Send Feedback Help > Get Involved Help > Donate to LibreOffice About > Release Notes
(In reply to Heiko Tietze from comment #18) > Please check which of the following links fail with zh instead of zh-cn: > > Help > User Guides > Help > Get Help Online > Help > Send Feedback > Help > Get Involved Ignore this, only donation and release notes work like this. > Help > Donate to LibreOffice > About > Release Notes
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2788cc07e9d0d078b53a7280d524175c03c51e12 Resolves tdf#127401 - Chinese locale pointing to wrong hub forward address It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #20) > https://git.libreoffice.org/core/commit/2788cc07e9d0d078b53a7280d524175c03c51e12 > […] > Affected users are encouraged to test the fix and report feedback. I'm not a dev but this doesn't sound like the right fix to me. .getBcp47() should return "zh-CN" (or "zh-TW", "pt-BR", "en-US", "fr", "it" etc) here. If it doesn't, then I think one should investigate why instead of adding ad-hoc fallback mappings :-P There are other places where the full language code is expected, not just these two. If for whatever reason the language code "zh-CN" changed to "zh" in the reference, then that should be reflected in the wiki. If it didn't, then the ad-hoc mapping might have political consequences and I don't think that should be our decision to make. Anyway, changing aLang from "zh" to "zh-cn" in /donation/ seems wrong, consider $ uri="https://hub.libreoffice.org/donation/" $ curl -sw "%{url_effective}\\t%{http_code} %{redirect_url}\\n" \ -o/dev/null "$uri?BCP47=zh-CN&LOlang=zh" \ -o/dev/null "$uri?BCP47=zh-CN&LOlang=zh-cn" \ -o/dev/null "$uri?BCP47=zh&LOlang=zh" \ -o/dev/null "$uri?BCP47=zh&LOlang=zh-cn" https://hub.libreoffice.org/donation/?BCP47=zh-CN&LOlang=zh 302 https://zh-cn.libreoffice.org/donate/?pk_campaign=hub&pk_kwd=program https://hub.libreoffice.org/donation/?BCP47=zh-CN&LOlang=zh-cn 302 https://www.libreoffice.org/donate/?pk_campaign=hub&pk_kwd=program https://hub.libreoffice.org/donation/?BCP47=zh&LOlang=zh 302 https://zh-cn.libreoffice.org/donate/?pk_campaign=hub&pk_kwd=program https://hub.libreoffice.org/donation/?BCP47=zh&LOlang=zh-cn 302 https://www.libreoffice.org/donate/?pk_campaign=hub&pk_kwd=program And replacing .getBcp47() with .getLanguage() in /ReleaseNotes/ is definitely wrong: Assuming a pt-BR but no pt translation, pt-BR users will be sent to the international (non-translated) version. Also, for releases where we have both zh-CN and zh-TW translations, the committed fix will send zh-TW folks to the zh-CN translation. Again, a potentially sensitive topic. $ uri="https://hub.libreoffice.org/ReleaseNotes/" $ curl -sw "%{url_effective}\\t%{http_code} %{redirect_url}\\n" \ -o/dev/null "$uri?LOvers=6.2&LOlocale=zh" \ -o/dev/null "$uri?LOvers=6.2&LOlocale=zh-cn" \ -o/dev/null "$uri?LOvers=6.2&LOlocale=zh-TW" \ -o/dev/null "$uri?LOvers=6.2&LOlocale=pt" \ -o/dev/null "$uri?LOvers=6.2&LOlocale=pt-BR" https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.2&LOlocale=zh 302 https://wiki.documentfoundation.org/ReleaseNotes/6.2/zh https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.2&LOlocale=zh-cn 302 https://wiki.documentfoundation.org/ReleaseNotes/6.2/zh https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.2&LOlocale=zh-TW 302 https://wiki.documentfoundation.org/ReleaseNotes/6.2/zh-tw https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.2&LOlocale=pt 302 https://wiki.documentfoundation.org/ReleaseNotes/6.2 https://hub.libreoffice.org/ReleaseNotes/?LOvers=6.2&LOlocale=pt-BR 302 https://wiki.documentfoundation.org/ReleaseNotes/6.2 (Yes, we don't have zh-TW ReleaseNotes for 6.4 and 7.0. But it's a wiki and translations can be added long after the release date.)
(In reply to Guilhem Moulin from comment #21) > ... one should investigate why instead of adding ad-hoc fallback mappings You are right, that is the correct solution. Reverting my patch and let the experts look into it.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6256b86f10d9a2bc51e72088192f3bfcf9d00437 Revert "Resolves tdf#127401 - Chinese locale pointing to wrong hub forward address" It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It turns out that the button on whatsnew infobar ("It seems this is the first time you are running <new_version>, would you like to have a look at what has changed?") links to the proper localized address. But I can't find the code for the infobar. I looked at sfx2/source/dialog/infobar.cxx and sfx2/source/view/viewfrm.cxx, but the closest I found is https://opengrok.libreoffice.org/xref/core/sfx2/source/view/viewfrm.cxx?r=107399d6#1338 . Any code pointers? Thanks.
After a bit more searching and looking at the previous patches for this bug, I think I found something. In sfx2/source/appl/appserv.cxx, which commit 787647b488d02be2acbbad4fa7873508dcb926c2 in comment 10 changed, and fixed this bug the first time, contains (line 558): "&LOlocale=" + LanguageTag(utl::ConfigManager::getUILocale()).getBcp47() while in cui/source/dialogs/about.cxx there is (line 99 and 100): "&LOlocale=" + LanguageTag(utl::ConfigManager::getUILocale()).getLanguage() Note the difference between getBcp47() and getLanguage(). Which one is used by infobar and which one is used by the About dialog link now? My guess is that the latter in about.cxx is used by the About dialog and wrong, it should also use getBcp47() instead, unless this would negatively affect other locales. BTW, I'm by no means a competent programmer, but it seems constructing this URL for release notes in two different places in code is not a very good idea...
(In reply to Ming Hua from comment #25) > Which one is used by infobar... (In reply to Commit Notification from comment #23) > Heiko Tietze committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 6256b86f10d9a2bc51e72088192f3bfcf9d00437 ^this (SID_WHATSNEW in sfx2/source/appl/appserv.cxx)
Ming Hua committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ce614dcc6d099ce14acae22b48dacf299ef470fb tdf#127401 Fix release notes URL for simplified Chinese (zh-CN) UI It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #27) > Ming Hua committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > ce614dcc6d099ce14acae22b48dacf299ef470fb > > tdf#127401 Fix release notes URL for simplified Chinese (zh-CN) UI I've dowlnloaded the Dec. 25th daily build that contains this commit: Version: 7.2.0.0.alpha0+ (x64) Build ID: ad9e04321df25824d2288a2ef1f4275f070f1cf7 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded And this bug is fixed now. I tested Chinese (simplified) UI and the URL in About dialog is "...&LOlocale=zh-CN" which will redirect to the correct wiki page (though it doesn't exist for 7.2 yet, but substituting "7.2" for "7.1" in URL show it works). Also tested other UI languages such as English (USA) (...&LOlocale=en-US), French (France) (=fr), and Japanese (=ja), and they all work as expected, so the commit should not have any bad side effects. Adolfo has already kindly cherry-picked this commit for 7-1 branch: https://gerrit.libreoffice.org/c/core/+/108179
Ming Hua committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/bbf7cf0da359dfdd0f6ee7516eb05a9adc8a2354 tdf#127401 Fix release notes URL for simplified Chinese (zh-CN) UI It will be available in 7.1.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.