Localize keyboard button texts (e.g. "Ctrl" -> "Strg")
There is one untranslatable item at Browsing "Enter full screen mode". Maybe you can make some button-texts translatable: "Ctrl", "Space", "PgUp", "PgDn", "Home", "End", "Backspace" maybe even those I would use the same Text in German as in English: "Shift", "Pause", "Alt", "Enter", "Esc"

re: "Enter full screen mode": I just added it last night. It should be picked up by Transifex today and be available for translation soon. ~~If you see it tomorrow we can close this issue 👍~~
Sorry just read again and it looks like you also want the button texts translatable too, I agree this is a good idea.
@bhousel 'full screen mode' arrived at transifex, thanks. Waiting for 'Ctrl' etc.
I've added the localizable button labels in c22fa60. These will appear on Transifex within the next day, and when they do, I'll add some translation instructions.
While it works for the "Keyboard shortcuts" screen, localization won't work yet in the popup tooltips. This is because iD.uiCmd() works a little differently than the iD.uiCmd.display() function that I added for the keyboard shortcuts. iD.uiCmd() generates a code in a specific way that a regex in d3.keybinding.js parses, so swapping e.g. "Ctrl" to "Strg" would mess it up.
Still trying to think of how I can reconcile the two approaches. Probably some combination of:
iD.uiCmdshould not do any display-focused translations, only conversions between win-mac-linux,- use
iD.uiCmd.display()everywhere we want a displayable code (like tooltips), and - change
iD.uiCmd.displayfrom accepting single character codes to accept a string (e.g."⌘A"), and return an array of keys found in it (e.g.['⌘ Cmd', 'A']). - maybe make another function to take that array and wrap those things in
<kbd>tags and join with<span>+</span>
The localizable button labels arrived at transifex
Thanks! I'm leaving it open until I can fix how the shortcuts are displayed in tooltips.
@bhousel Do you mean that you also want to display "Strg" + "<- Rück" here:

Do you mean that you also want to display "Strg" + "<- Rück" here:
Yes!
@bhousel is this still on your agenda?
@1ec5 hello, I'm interested to solve this issue, is there something which I should know other than the previous comments? I'm new to open source and been tested the repository on my local.
I've started to work on it.
Sure, feel free to post a pull request for review when you’re ready. Per https://github.com/openstreetmap/iD/issues/4090#issuecomment-359428212, the only thing left to do here is update tooltips to also localize the modifier key names.
You’ll need to be using either Windows or Linux to see the key names, because on macOS, language-independent key symbols appear in the tooltips instead. In your local environment, append the language parameter to the URL to test iD in a particular language, for example, &language=de for German.
Here’s an example of where a tooltip shows shortcut keys (specifically, when hovering over the Show History Panel checkbox in the Map Data panel):
https://github.com/openstreetmap/iD/blob/b5d45e3f28ccb9a39d243e7504415152e1ce8ec2/modules/ui/sections/data_layers.js#L404
That calls into a function that hard-codes English names, which seems promising. However, it’s right next to the code that was fixed in c22fa60b8a33fdfd9dc668619a797f8c2889f9ad, so there must be a reason why it wasn’t changed. This function might be used elsewhere where it needs to retain the raw English names, in which case you might need to find a different way to localize these key names.
Sure, feel free to post a pull request for review when you’re ready. Per #4090 (comment), the only thing left to do here is update tooltips to also localize the modifier key names.
You’ll need to be using either Windows or Linux to see the key names, because on macOS, language-independent key symbols appear in the tooltips instead. In your local environment, append the
languageparameter to the URL to test iD in a particular language, for example,&language=defor German.Here’s an example of where a tooltip shows shortcut keys (specifically, when hovering over the Show History Panel checkbox in the Map Data panel):
https://github.com/openstreetmap/iD/blob/b5d45e3f28ccb9a39d243e7504415152e1ce8ec2/modules/ui/sections/data_layers.js#L404
That calls into a function that hard-codes English names, which seems promising. However, it’s right next to the code that was fixed in c22fa60, so there must be a reason why it wasn’t changed. This function might be used elsewhere where it needs to retain the raw English names, in which case you might need to find a different way to localize these key names.
Thank you so much for providing such a clear and detailed explanation of this issue, I’ll review the mentioned areas and proceed with the updates as suggested.
I'm on MacOS but will try to figure out somehow.
So, I approached this issue in mentioned way, I got a bit familiar and saw that,
In the local environment, append the language parameter to the URL to test iD in a particular language doesn't seem to work directly as http://localhost:8080/?language=de doesn't change the language unless the computer system language is set to that particular language or any browser extension forcibly change the language of the webpage.
I used UserSwitcherAgent Extension setting to Windows Browser Environment like Internet Explorer and Locale Switcher Extension to convert on English to German (Device used MacOS Sequoia 15.1)
On it! It's very Interesting ))
Sorry, I should’ve been clearer: iD doesn’t use real URL query parameters; instead, it uses a similar syntax as the URL hash (after the #), so that the hash can update dynamically as you pan the map, select features, etc.
No problem, hopefully I'll be able to push a quality PR to this issue.
Sorry, I don't know if this is the right approach,
But since only modifiers key names is left to be localised,
I plan to create a function that: Detects the system language. Parses the corresponding JSON file for the language. Dynamically replaces hardcoded modifier key names with localized ones.
Would parsing the JSON file dynamically at runtime be a feasible approach? Let me know if I’m heading in the right direction.. Thank you for your time and guidance.
Update :
I found I should exactly work,
I rely on the user agent string to determine the platform and simulated it as a Windows-based user agent
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36
For example, like for german Language
Now I think I need to localise this portion of
CTRL + Shift + t('info_panels.history.key') into STRG + Umschalt + t('info_panels.history.key')
Update 2 :
At line 20 in cmd.js :
var result = '',
replacements = {
'⌘': 'Ctrl',
'⇧': 'Shift',
'⌥': 'Alt',
'⌫': 'Backspace',
'⌦': 'Delete'
};
so if we make the line number 20-26 like below,
var mac = (detected.os === 'mac');
var result = '',
replacements = {
'⌘': mac ? t('shortcuts.key.cmd') : t('shortcuts.key.ctrl'),
'⇧': mac ? t('shortcuts.key.shift') : t('shortcuts.key.shift'),
'⌥': mac ? t('shortcuts.key.option') : t('shortcuts.key.alt'),
'⌫': mac ? t('shortcuts.key.delete') : t('shortcuts.key.backspace'),
'⌦': mac ? t('shortcuts.key.del') : t('shortcuts.key.del'),
};
Above Changes, I think would be more better for this function to work more dynamically according to the localization ?
It would correctly translate like this...
should I go ahead for a PR?
Proposed Changes below for file cmd.js from line 20 to 26:
var mac = (detected.os === 'mac');
var result = '',
replacements = {
'⌘': mac ? t('shortcuts.key.cmd') : t('shortcuts.key.ctrl'),
'⇧': mac ? t('shortcuts.key.shift') : t('shortcuts.key.shift'),
'⌥': mac ? t('shortcuts.key.option') : t('shortcuts.key.alt'),
'⌫': mac ? t('shortcuts.key.delete') : t('shortcuts.key.backspace'),
'⌦': mac ? t('shortcuts.key.del') : t('shortcuts.key.del'),
};
@1ec5 Please let me know if I'm missing out on something on https://github.com/StillAbeginnerr/iD/commit/672b376cfaac236c5142d097eb8cee09ec7275ba
Thanks for posting #10570 – let’s continue the discussion about your implementation there.