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

Content bug: <browser compatibility link invalid in Non-English page> #3882

Closed
wssdll opened this issue May 25, 2021 · 4 comments · Fixed by #3883
Closed

Content bug: <browser compatibility link invalid in Non-English page> #3882

wssdll opened this issue May 25, 2021 · 4 comments · Fixed by #3883

Comments

@wssdll
Copy link

wssdll commented May 25, 2021

What page(s) did you find the problem on?

It is a widespread problem over many pages.

There is an example:
https://developer.mozilla.org/zh-CN/docs/Web/API/ResizeObserver#browser_compatibility

Specific page section or heading?

The experimental label, #browser_compatibility link.

What is the problem?

The experimental label, #browser_compatibility archor link cannot be positioned correctly.

image

I think it’s because of the incorrect ID translated.

image

What did you expect to see?

There is a correct example:
https://developer.mozilla.org/ja/docs/Web/API/WritableStream#browser_compatibility

Did you test this? If so, how?

Manual test.

@hamishwillee
Copy link
Contributor

@escattone @peterbe This should probably move to yari (but I don't have the magic power).

Essentially the translated string for this (and other) macros uses the same hard coded anchor #browser_compatibility for the browser compatibility section - for Japanese you can see it here: https://github.com/mdn/yari/blob/main/kumascript/macros/SeeCompatTable.ejs#L7

The "easy" fix would be to translate the anchor too, but then of course we have to let the translators know what the standard name for this section should be. Maybe a better approach would be to include the anchor browser_compatibility in the code generated by the macro - presumably then it will use the heading anchor if it exists and go straight to the macro if not. Just a thought.

@peterbe
Copy link
Contributor

peterbe commented May 25, 2021

The problem is that https://github.com/mdn/translated-content/blob/50513730f1bfcc9ec23f19600f756606c2498d52/files/zh-cn/web/api/resizeobserver/index.html#L66 should be changed to:

<h2 id="browser_compatibility">浏览器兼容性</h2>

but I'm a bit surprised why it didn't do that automatically at build-time.

@peterbe
Copy link
Contributor

peterbe commented May 25, 2021

Now I understand why it doesn't "force" it to become id="browser_compatibility" in build-time. If the <h2> has an id it takes that.

I was wrong in saying that it should be changed to:

<h2 id="browser_compatibility">浏览器兼容性</h2>

It can remain as:

<h2 id="浏览器兼容性">浏览器兼容性</h2>

But we'll need to change the SeeCompatTable.ejs macro for zh-CN.

@peterbe peterbe transferred this issue from mdn/content May 25, 2021
@peterbe peterbe assigned peterbe and unassigned escattone May 25, 2021
peterbe added a commit to peterbe/yari that referenced this issue May 25, 2021
@github-actions github-actions bot added the 🐌 idle Issues and PRs without recent activity. Flagged for maintainer follow-up. label Dec 8, 2021
@liyuhang1997
Copy link

I think we should translate SeeCompatTable.ejs and keep existing page id corresponding to language.

@github-actions github-actions bot removed the 🐌 idle Issues and PRs without recent activity. Flagged for maintainer follow-up. label Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

5 participants