Docusaurus: onPageNav links not working for headings written in Chinese

[ChaoyueZhao]

Is this a bug report?

yes

Have you read the Contributing Guidelines on issues?

yes

Environment

Web browser

Steps to Reproduce

1. write markdown file in Chinese, using headings like "### 第一章"、“## 第二节”
2. set onPageNav: 'separate' in siteConfig.js
3. heading links on the right side of that page are not able to navigate page to the heading section, slug only show "baseURL/#"

Expected Behavior

expect it to decode Chinese characters and generate a Pinyin slug for best SEO.

I tested with Japanese headings, also not working , but Spanish, Franch works fine.

[microbouji]

Confirming as a bug. The on-page nav currently uses the existing toSlug function which apparently removes non-ascii characters. Should be easy to swap with another slug generator like uslug.

[JoelMarcey]

@microbouji Nice find. Thanks. Is that something you would want to send a PR for?

[microbouji]

Can do. Not sure which slugiffier to use though. uslug linked above preserves the unicode characters as part of the slug. node-slug on the other hand does romanization as described by @ChaoyueZhao

[JoelMarcey]

node-slug seems to be the more popular one, right? Maybe we try that one first to see if it solves the problem without causing other problems?

[SleepWalker]

@JoelMarcey , @microbouji please look at my PR too (yep, this bug was fixed a month ago :disappointed: ):

• there are no extra dependencies
• all covered with tests
• it ensures anchor uniqueness
• does not uglify non latin anchors. E.g. it will generate #第二节” instead of #di-er-jie

[JoelMarcey]

@SleepWalker Hi. Sorry it took so long to get to your PR. I do like the fact that tests exists. That is a big plus. The question is whether or #559 provides all that functionality with just the added dependency. Are you thinking that the added dependency is actually worse than what your PR provides?

@microbouji, what do you think here about #492?

[SleepWalker]

@JoelMarcey #559 should be enough for this issue. Regarding #368, I can re-submit my PR with fixes only for that issue.

Are you thinking that the added dependency is actually worse than what your PR provides?

I think, that both solutions are ok. They provide different anchor styles. We should select the one, that suits better.

In my PR anchors are similar to github's. The ugly part of my solution is that I've copy-pasted regexps, because we have no babel here (alternatively we could add of xregexp as a dependency, but I think it's too much for one tiny function).

The advantage of transcript from #492 is that urls will be a little bit nicer on some browsers, that url encode the hash part (e.g. #di-er-jie instead of #%E7%AC%AC%E4%BA%8C%E8%8A%82%E2%80%9D).