Here is new Compose file for the am_ET.UTF-8 locale. xkeyboard-config has already got an 'et' symbols for the part of the alphabet. The rest is implemented as a Compose file
Created attachment 10369 [details] Compose file for am_ET.UTF-8
Sergey, I note that this compose table contains entries which start with the key <c>, but that symbol does not exist in xkeyboard-config/symbols/et. Has this compose table fallen out of sync with the keyboard in xkeyboard-config?
And I forgot to ask: do you also have XI18N_OBJS and XLC_LOCALE.pre files written to go along with the Compose file?
> I note that this compose table contains entries which start with the key <c>, > but that symbol does not exist in xkeyboard-config/symbols/et. You're right, I'll add these "dead" symbols ASAP.
No, I do not have these files. I would copy them from, say, en_US.UTF-8. I simply have no information to compose them. I'll ask Jim Gettys - may be, he'd find somebody...
I've committed missing C key, thanks for spotting it.
Pushed in commit 4ec1723fff729440cd3349c1f95d87d2a6ba89cf. That done, should new dead key symbols be added to keysymdef.h and used instead of using ASCII characters as dead keys? We could (should?) add an XK_ETHIOPIC section modeled after the XK_BRAILLE section.
> Pushed in commit 4ec1723fff729440cd3349c1f95d87d2a6ba89cf. Thanks! > That done, should new dead key symbols be added to keysymdef.h and used instead > of using ASCII characters as dead keys? It is a very good question. What is the general policy here? I do not mind either way. What's bad about using ordinary ASCII as dead keys (if they are not used as normal keys in that layout)?
(In reply to comment #8) > What's bad about using ordinary ASCII as dead keys > (if they are not used as normal keys in that layout)? Yes, I should have continued the thought. Sorry about that. The benefits I see are “correctness” — for some definition thereof ☺ — and the ability to merge the compose table into en_US.UTF-8/Compose.pre. (Until now am_ET.UTF-8/Compose has been an alias for en_US.UTF-8/Compose.)
OK, it makes sense. If you'd push new deadkeys into keysymdef - at some point later I'd make corresponding changes in xkeyboard-config. But I am not sure merging this very specific Compose into en_US is a good idea in general.
(In reply to comment #10) > OK, it makes sense. If you'd push new deadkeys into keysymdef - at some point > later I'd make corresponding changes in xkeyboard-config. I don't want to push it unilaterally, so we'll see whether anyone comments.... > But I am not sure > merging this very specific Compose into en_US is a good idea in general. Presumably someone operation in the am_ET.UTF-8 locale needs to type more than just Ge'ez/Amharic/Tigrigna, and so will probably want to have et and something like us(intl) on separate groups for easy switching, and since the Compose file is chosen based on $LOCALE, it seems beneficial to merge all of the UTF-8 Compose files into one.
> I don't want to push it unilaterally, so we'll see whether anyone comments.... OK. > is chosen based on $LOCALE, it seems beneficial to merge all of the UTF-8 > Compose files into one. Yes it makes sense. Anyway, it's up to you, you maintain this package, so you better understand the general policy here. But it is possible only after new dead keysyms are approved (and even after that, different exotic layouts might have different views on how to use dead_c)
It looks like nobody complained. Did this ever get pushed? If not, can we push it?
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
(In reply to Sergey V. Udaltsov from comment #8) > > That done, should new dead key symbols be added to keysymdef.h and used instead > > of using ASCII characters as dead keys? > It is a very good question. What is the general policy here? I do not mind > either way. What's bad about using ordinary ASCII as dead keys (if they are > not used as normal keys in that layout)? Because you cannot type ASCII anymore then. Not even switching the keyboard layout helps. If you run in am_ET.UTF-8 locale, the compose file /usr/share/X11/locale/am_ET.UTF-8/Compose is used. And if that file contains something like <u> <U1200> : "ሁ" U1201 # key h (base character ሀ) it becomes impossible to type a normal u. No matter what keyboard layout you use, switching to US English keyboard layout doesn’t help. One can type an x because no sequence starts with <x> in /usr/share/X11/locale/am_ET.UTF-8/Compose but on cannot type an u. One would need to switch to another locale to type an u. And as switching locales on the fly is not really an option, this does not make sense.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.