I strongly suggest to list assigned keyboard hotkeys in all of the available tooltips. This is a small, but very important usability issue:
I can definitely support this! 
Displaying hotkeys in menus and tooltips would be a really efficient way to teach the user more faster ways to do things. It can improve hotkey usability drastically.
1 Like
+1
This is one of the best and easiest ways to learn keyboard shortcuts.
I came here about to make the same suggestion. Even created a screenshot:
How has this not been implemented in 3+ years? Seems like one of the simplest things to implement, lowest hanging fruit. There’s enough demand it appears as a Google search suggestion:
This would NOT have happened if Obsidian were open-source. Even non-coders could’ve identified the string “Open quick switcher” and added the hotkey for it (Ctrl+O).
It sounds easy, and it’s not too hard to code, but this is way to simplified an suggestion on how this would be coded.
Remember that all texts are to be translated, so the place where you find that particular text is not where the tooltip is defined. It’s also most likely all the static text for that language, so no context is really given. Maybe that phrase is even used multiple places, and not only to depict a command?
In addition hotkeys are possible to redefine and different on various OS’s, so it’s not just a matter of adding Ctrl+O. You need to keep track, and add the current one before presenting the tooltip.
And it’s definitely not at easy as “go open source, and all issues are solved”. If you’ve been around for long enough, you’ll now there are plenty of issues within open source projects not being solved.
You can even look within our plugin scope to find examples. How many plugins are there which are more or less abandoned, even if used by a multitude of users? Couldn’t the coders “just fix that issue”, since they’re practically open source?
In short, it would be nice to have the hotkey shown, but don’t over simplify the task associated with it. And even more, be kind and supportive of the developers who have quite a lot on their plate. A happy and content programmer is way more efficient, than one being told to implement this already.
2 Likes
I worked in L10n for ~4 years, so I know how translating application resources works: the code uses string identifiers instead of raw strings, and resource files with those identifiers paired with the English text. These are handed over to localization shops (or just an LLM nowadays), received back translated, and the code picks up the string IDs for the intended locale.
Side note: I think software localization is shooting ourselves in the foot as an international species, and continuing a synchronization problem we haven't been able to solve since "Babylon" - that of agreeing on one international lingua franca *and actually using it*. I wrote in detail about this on [Why the world would be a better place if we all used English](https://www.linkedin.com/pulse/why-world-would-better-place-we-all-used-english-dan-dascalescu/). TL;DR - translation has been costing humanity more per year than curing hunger.Anyway, back on topic:
Maybe that phrase is even used multiple places, and not only to depict a command?
That would be bad practice; different identifiers are used for different context, even if the text happens to be the same. I don’t think the Obsidian devs would do this.
How many plugins are there which are more or less abandoned, even if used by a multitude of users?
Plugins have a far smaller user base than Obsidian; well below the critical mass.
And even more, be kind and supportive of the developers
Amen to that! 
who have quite a lot on their plate.
Wish I could help… But alas, it’s closed source. Which isn’t a bad thing - I’ve read their rationale and agree with it. Except we’re talking about a kind of trivial change here, not what point 2 envisions as an obstacle:
Open source does not necessarily mean faster improvement. Code is not just text that can be easily understood and manipulated; one needs to understand the code architecture
Not for patching a resource string.
That’s about the only “difficulty”. But the core team only needs to provide that logic for one button, then it can be copied to all others, likely abstracted away under a function call.
Would be interested if some sort of open source hybrid existed where microtasks could be farmed out without disclosing the entire code base.