Add keyboard shortcut help dialog to discover available shortcuts (? key)

[choo121600]

Why

The UI includes many keyboard shortcuts, but there is currently no way to discover them.
This PR adds a help dialog that can be opened with ? and shows the shortcuts available on the current page, grouped by category.

How

Shortcuts register themselves when mounted, so the dialog always reflects the shortcuts that are actually available.
A thin useShortcut wrapper around useHotkeys provides this functionality without changing existing shortcut behaviour.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

claude opus 4.8

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Interesting! I think we should get rid of the keyboard tooltip on the Grid view while we are at it then.

[bbovenzi]

Final note. I think we should keep a json file of all the existing shortcuts in one place instead of the useShortcut building the list on render.

A single file source of truth will be much easier for maintainers to know what shortcuts already.

[choo121600]

@bbovenzi Just to make sure I understand the suggestion correctly, are you primarily looking for:

• A single source of truth for shortcut definitions (e.g. a central catalog/JSON file), while keeping the dialog scoped to shortcuts available on the current page?
• The help dialog itself to always show the complete list of shortcuts, regardless of the current page?

The current implementation intentionally uses the live registry so the dialog only shows shortcuts that are actually available in the current context.

[bbovenzi]

@bbovenzi Just to make sure I understand the suggestion correctly, are you primarily looking for:

• A single source of truth for shortcut definitions (e.g. a central catalog/JSON file), while keeping the dialog scoped to shortcuts available on the current page?
• The help dialog itself to always show the complete list of shortcuts, regardless of the current page?

The current implementation intentionally uses the live registry so the dialog only shows shortcuts that are actually available in the current context.

The first one. I think having a single source of truth in the code would help with maintainability. We can have nested objects in the json block for global vs per page shortcuts though.

[choo121600]

How about keeping the catalog as a .ts file instead of JSON?
entries stay type-checked at the definition site (satisfies CategorizedShortcuts), so a typo'd category fails to compile instead of silently dropping the shortcut from the help dialog.

Happy to switch to JSON if you'd prefer, though.

[ashb]

An idea: Should the shortcut keys themselves also be localized/translated?

[ashb]

Nit: should the shortcuts we show be scoped down to the current page?

[bbovenzi]

@choo121600 yes a ts file works for me.

[choo121600]

Nit: should the shortcuts we show be scoped down to the current page?

This is already the current behavior :) The modal renders from a live registry rather than the static catalog.
Each useShortcut registers on mount and unregisters on unmount (and is skipped when enabled is false), so the modal only displays shortcuts that are active on the current page.

Dag Page

DagRun Page

An idea: Should the shortcut keys themselves also be localized/translated?

I'm not sure whether the key combinations themselves should be localized.
Things like Ctrl and Shift are currently part of the translation strings, but when working on the Korean translations I've been keeping them as-is rather than translating them.