Make screen reader section labels translatable

withastro / docs

Astro documentation

https://docs.astro.build/

MIT License

1.34k stars 1.51k forks source link

Make screen reader section labels translatable #1586

Closed delucis closed 1 year ago

delucis commented 2 years ago

We use custom configuration rehype-autolink-headings to wrap our headings and add the clickable link icon. This includes a screenreader label which we inject but this is currently hardcoded in English:

https://github.com/withastro/docs/blob/41ea6653d78cfa90d96cd41019dbf1440a07f2af/astro.config.ts#L37

We should make this translatable like our other language strings.

yanthomasdev commented 2 years ago

Thanks for raising this issue @delucis!

Considering rehype/remark plugins have no way of knowing the currently selected language (at least that I can think of), I can think of some ways of tackling this:

Wait for the future docs migration to MDX and use a custom component that wraps headings and adds the screen reader label translated.
Make a simple client-side script that changes the clickable icon label to be in the correct language.

Any thoughts on this? Of course, we could go with the second option till we migrate to MDX. It would be amazing to have a zero JS solution for this but I think it's not possible, though feel free to surprise me!

delucis commented 2 years ago

I wonder if there actually is a way to do this at the remark plug-in level? I know Hippo added the (EN) suffix to links to fallback pages. Does that plug-in show how to get the current language of a page perhaps?

delucis commented 2 years ago

Yes!

https://github.com/withastro/docs/blob/e8072d37c207521c8f7e12fcc9e0f7f69c40156c/plugins/remark-fallback-lang.ts#L13

yanthomasdev commented 2 years ago

Yes!

Oh, sweet! Glad you surprised me. Though, at first glance, it looks like we'd need to have access to the syntax tree to get the current page, which we can't get through the config file. In the worst-case scenario, I would need to rewrite the plugin, which doesn't look like a complicated task after digging into its source code.

Alternatively, we might only need to make a new plugin that changes the syntax tree after the rehype plugin is run, only applying the language changes (I haven't found anything about remark/rehype plugins being able to affect one another nor if you can define a specific running order like Vite plugins yet - will take a closer look soon!)