3966 update glossary

[dhtclk]

Summary

Adding custom tooltips that have been injected via script, based off of a json file generated off of the current glossary page. This was executed on concepts and getting-started pages only as a first pass to reduce scope.

Checklist

• Delete items not relevant to your PR
• URL changes should add a redirect to the old URL via https://github.com/ClickHouse/clickhouse-docs/blob/main/docusaurus.config.js
• If adding a new integration page, also add an entry to the integrations list here: https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/integrations/index.mdx

ClickHouse.Docs.Glossary.Tooltip.mp4

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
clickhouse-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 28, 2025 8:46pm

3 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
clickhouse-docs-jp	⬜️ Ignored (Inspect)			Jul 28, 2025 8:46pm
clickhouse-docs-ru	⬜️ Ignored (Inspect)	Visit Preview		Jul 28, 2025 8:46pm
clickhouse-docs-zh	⬜️ Ignored (Inspect)	Visit Preview		Jul 28, 2025 8:46pm

[Blargian]

Wow! This looks super cool! 👏

I've just been looking through and realised there is one challenge to this I hadn't considered before, which is that when we run the translations the LLM is not going to know what to do with this component in the markdown. It will translate the text around it and we will be left with the translation and glossary words still in English, so by introducing this component around the words we're "polluting" the markdown a little bit.

I also wonder how this affects LLMs as they parse the markdown?
This is something we could maybe ask the folks at Kapa. We should make sure that our Ask AI is not going to spit out the component name, mistaking it as part of the text.

One potential solution is that we insert these components only when we build the docs. We should be able to do this using the Docusaurus life cycle hooks but then processing becomes trickier.

What if we introduced some custom markdown syntax like ^^ ^^ for glossary terms? E.g A data ^^part^^ is .... Then at build time the custom docusaurus plugin running on the hook will transform ^^ ^^ into <Glossary/>. This way we don't change the text too much. I can point to some code we have already that does some of this.

Thoughts?

[dhtclk]

@Blargian - You bring up some really good points. I think this is something that we need to address, I'll look into transforming custom markdown syntax, great idea.

[dhtclk]

@Blargian - Updates have been made for the new approach for tool tips, along with added steps to extract the current glossary terms and check if terms are appropriately wrapped in the docs. This will only surface a warning and will not fail the build. You'll see something like this on success.