[orca-list] Keybindings handling mehanishm refactoring: fit this change with Orca 3.12 cicle?

[Hammer Attila <hammera pickup hu>]

Dear Joanie,

Non english language keyboard layouts some time some Orca laptop 
keybindings conflicting with other Orca commands if the user not using 
the keyboard layout list primary with english keyboard layout.
I no, if the problem affecting only one person, good answer to please 
define an another keybinding the conflicting commands, but this problem 
affecting more hungarian Orca users and perhaps another non english 
language users.
Few typical examples the hungarian keyboard layout related:
1. Orca find dialog laptop keybinding is Orca modifier+bracketleft, and 
present text attributes command is orca modifier+f combination. Because 
in hungarian keyboard layout bracketleft key possible only activating 
with right alt+F keystroke, when I press Orca modifier+f keystroke to 
listen actual text attributes, Orca presenting the search dialog.
2. Sayall command is orca modifier+semicolon, spoken actual character is 
orca modifier+comma. Because in hungarian keyboard layout the semicolon 
character possible activating only with right alt+comma combination, 
when I press orca modifier+comma keystroke, Orca doing a sayall 
operation and not spokening the actual character with flat review.
Changing hungarian standard keyboard layout is not a good fix method, 
because other operating system use this standard too with hungarian 
keyboard layout.

This character mapping replacement related I have got a centralized 
idea, depending the actual locale setting:
If translators have optional possibility to define a locale depending 
dictionary to solve this conflicts, Orca future need dinamicaly replace 
the proper keybindings with locale depending part.
An example dictionary structure, centralized filename is 
hu_HU_keybindings.dic, or de_DE_keybindings.dic:
keybindings: {
"data: [
{
"original": "semicolon",
"replace": "eacute",
"pronounce": "é"
},
{
"original": "bracketleft",
"replaced": "odoubleacute",
"pronounce": "ő"
}
]
}

What meaning this fields in this dictionary?
The first two field is not interesting, good understandable the purpose. 
The pronounce field is important only when Orca presenting keybindings 
page the Orca bindings and Orca list shortcuts feature, better seeing 
normal locale depending letters a non english language, hungarian 
language absolute sure.

What your openion this fix way? This problem is not affecting only with 
one distribution, downstream level difficult fixing this problem with 
non english layouts with affected.
I think add this character replacements with Orca translator files is 
not a good way, perhaps disturb this change with other Orca translators 
with not need this feature. For example an english language environment 
not need translating bracketlef keybinding part and semicolon part. If 
this conflicts added for example the translation files, this is 
generating more unneed strings with not affected locales.
Because this way an optional possibility to handle the conflicting 
bindings a centralized way, I think this is the best solution if you not 
have better ydea.

Attila