zh_HANS-CN: do separate hyperlink from the next word with a space#131
Merged
jnavila merged 1 commit intojnavila:masterfrom Mar 1, 2025
Merged
zh_HANS-CN: do separate hyperlink from the next word with a space#131jnavila merged 1 commit intojnavila:masterfrom
jnavila merged 1 commit intojnavila:masterfrom
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 <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git-scm.com
that referenced
this pull request
Feb 26, 2025
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 <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git-scm.com
that referenced
this pull request
Feb 26, 2025
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 <johannes.schindelin@gmx.de>
dscho
added a commit
to git/git-scm.com
that referenced
this pull request
Mar 1, 2025
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 <johannes.schindelin@gmx.de>
Owner
|
Thank you for the this fix. I'm not sure I can come up with an early check on these types of errors. |
Contributor
Author
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 ;-) |
dscho
added a commit
to dscho/git-scm.com
that referenced
this pull request
Sep 5, 2025
In c902ac8 (ci: check for broken git-scm.com links, 2025-02-27), I added a work-around for a link that had been broken in advertently, in a repository different from git-scm.com. I contributed a fix for that with jnavila/git-manpages-l10n#131, but did not want to have git-scm.com's link check to keep failing until that fix was merged. Well, the work-around is no longer necessary because my fix has been merged in the meantime. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.