Skip to content
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

Merged
merged 1 commit into from
Mar 1, 2025

Conversation

dscho
Copy link
Contributor

@dscho dscho commented Feb 26, 2025

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.

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]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
@jnavila
Copy link
Owner

jnavila commented Mar 1, 2025

Thank you for the this fix.
More generally, asciidoc is quite western-centric concerning how inline formatting is parsed, and it expects spaces where the CJK languages do not use them.

I'm not sure I can come up with an early check on these types of errors.

@jnavila jnavila merged commit f3c105e into jnavila:master Mar 1, 2025
1 check passed
@dscho dscho deleted the fix-link-to-git-scm.com branch March 1, 2025 21:28
@dscho
Copy link
Contributor Author

dscho commented Mar 1, 2025

asciidoc is quite western-centric concerning how inline formatting is parsed, and it expects spaces where the CJK languages do not use them.

It's not the only Wester-centric bias within the Git ecosystem ;-)

I'm not sure I can come up with an early check on these types of errors.

TBH neither can I. At least now that I merged git/git-scm.com#1960, we will have a non-early check ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants