-
Notifications
You must be signed in to change notification settings - Fork 233
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
zh_HANS-CN: do separate hyperlink from the next word with a space #131
Conversation
Git's website at https://git-scm.com/ uses Hugo to prepare the HTML pages, and Hugo tries to translate bare HTTP/HTTPS links to proper HTML links. It apparently uses similar heuristics to human beings when determining where a link ends and the next word starts. For example, it considers "https://git-scm.com/docs上查看。" to be a hyperlink followed by a full stop. That is, it considers "上查看" _part_ of the hyperlink because there is no space or any other separator between the _actual_ hyperlink and the following text. This part of the translation was introduced in 8b72a13 (Translated using Weblate (Chinese (Simplified)), 2023-02-11) and has been subsequently touched by 8b73fac (mass type fixups in constant strings, 2023-12-21), 51ad8a5 (run check_po script to find discrepancies in the po files, 2024-02-07), and fcb0f4e (Translated using Weblate (Chinese (Simplified)), 2024-02-08), neither of which inserted a space between the hyperlink and the following text. As a consequence, the last hyperlink in the section at https://git-scm.com/docs/git/zh_HANS-CN#_%E6%8F%8F%E8%BF%B0 is incorrect. Let's rectify this. Signed-off-by: Johannes Schindelin <[email protected]>
There is specific code in git-scm.com's deploy workflow to open a ticket whenever broken links were detected, and to close such a ticket when no broken links were detected. However, as per lycheeverse/lychee-action#265 the way we checked for this was incorrect: `env.lychee_exit_code` had was correct, until lycheeverse/lychee-action#245 broke it by way of fixing another bug. This was the reason why the broken link that was found and reported in https://github.com/git/git-scm.com/actions/runs/13544529063/job/37852881418#step:3:135319 never made it into a GitHub issue, even if that had been the intention. For the record, I worked on a fix for this broken link and opened jnavila/git-manpages-l10n#131 to incorporate that fix. What prevented this broken link from being detected before above-mentioned deployment is the fact that before git#1953 was merged, the `git-scm.com` deployment used `http://` in the base URL, and hence the `--remap` option used in the deployment workflow mapped all http://git-scm.com links to local files, whereas now the `https://` base URL is used and https://git-scm.com links are mapped, including the offending one. In any case let's fix opening/closing the "broken link" issues. Signed-off-by: Johannes Schindelin <[email protected]>
There is specific code in git-scm.com's deploy workflow to open a ticket whenever broken links were detected, and to close such a ticket when no broken links were detected. However, as per lycheeverse/lychee-action#265 the way we checked for this was incorrect: `env.lychee_exit_code` had was correct, until lycheeverse/lychee-action#245 broke it by way of fixing another bug. This was the reason why the broken link that was found and reported in https://github.com/git/git-scm.com/actions/runs/13544529063/job/37852881418#step:3:135319 never made it into a GitHub issue, even if that had been the intention. For the record, I worked on a fix for this broken link and opened jnavila/git-manpages-l10n#131 to incorporate that fix. What prevented this broken link from being detected before above-mentioned deployment is the fact that before git#1953 was merged, the `git-scm.com` deployment used `http://` in the base URL, and hence the `--remap` option used in the deployment workflow mapped all http://git-scm.com links to local files, whereas now the `https://` base URL is used and https://git-scm.com links are mapped, including the offending one. In any case let's fix opening/closing the "broken link" issues. Signed-off-by: Johannes Schindelin <[email protected]>
Not all links are relative in the PR build; Some of the links originate from Git's manual pages or from the ProGit book or its translations, and those links are of the form "https://git-scm.com/...". Let's map those into "file:///..." URLs so that lychee checks them even in offline mode. This uncovers a broken link which is address by jnavila/git-manpages-l10n#131. For the time being, this patch adds a work-around specifically for that issue lest contributors' PRs fail through no fault of their own. Signed-off-by: Johannes Schindelin <[email protected]>
Thank you for the this fix. I'm not sure I can come up with an early check on these types of errors. |
It's not the only Wester-centric bias within the Git ecosystem ;-)
TBH neither can I. At least now that I merged git/git-scm.com#1960, we will have a non-early check ;-) |
Git's website at https://git-scm.com/ uses Hugo to prepare the HTML pages, and Hugo tries to translate bare HTTP/HTTPS links to proper HTML links. It apparently uses similar heuristics to human beings when determining where a link ends and the next word starts.
For example, it considers "https://git-scm.com/docs上查看。" to be a hyperlink followed by a full stop. That is, it considers "上查看" part of the hyperlink because there is no space or any other separator between the actual hyperlink and the following text. This part of the translation was introduced in 8b72a13 (Translated using Weblate (Chinese (Simplified)), 2023-02-11) and has been subsequently touched by 8b73fac (mass type fixups in constant strings, 2023-12-21), 51ad8a5 (run check_po script to find discrepancies in the po files, 2024-02-07), and fcb0f4e (Translated using Weblate (Chinese (Simplified)), 2024-02-08), neither of which inserted a space between the hyperlink and the following text.
As a consequence, the last hyperlink in the section at https://git-scm.com/docs/git/zh_HANS-CN#_%E6%8F%8F%E8%BF%B0 is incorrect.
Let's rectify this.