Bug 22649

Note that the current workaround is to define a keysym for each combo
and add that to the compose table with the desired string as output.

Cf the Arabic ligatures in the en_US.UTF-8/Compose table.

+1 This is really a frequent problem, it needs a stable clear policy, not a geeky workaround. The digital divide is big enough without adding trouble from our side.

I now exactly have this problem. This issue will come up over and over again during the next weeks/months depending on which less resourced languages I am/we are going to work with.

this will hopefully be supported in xkb2.

A friend of mine has asked me to share my expertise in computational linguistic with you. Although I am not familiar with the language except the information I got from Wiki, but I would like to share my experience as on Kurdish with you. We had the same problem back in 1992 with Kurdish written in many non standard systems. Therefore I went for re-codifying and unifying all the systems into one to free the writing experience for any age on any level. see more at www.kurdishacademy.org

What I see in relation to Udmurt is a classical issue with codified language with too many singular cases that does not appear in any other languages so it can not be covered by Unicode or any other standard. You will need to look into digraph and trigraph cases to cover the rear cases instead of creating very odd single letters. This will make the codification more standard friendly. It is better for the future of the language in electronic medium. 

You need to always see the concept from a 7 years old kid's perspective otherwise the language learning will become a sophisticated experience for computer experts. This is important for the survival of the language in new rapid electronic era.

I've been reading the comments on the bug and I tried my luck with the
"current workaround" as suggested by James Cloos, but I seem to be to
dumb to get the logics behind it. The proposed example with Arabic
ligatures in the us_utf8/Compose file sounded promising, but turned
out to be quite cryptic.

On having a look at a Fedora box the only such locale I find is in:
/usr/share/X11/locale
it's already quite a mystery why a handful of locales would be here,
while everything else is under /usr/share/locale (but okay, let's
assume there's a good reason).

In the locale dir I do get a Compose file, authored by David Monniaux
which in turn has a snippet that goes
....
#
# Arabic Lam-Alef ligatures
#

<UFEFB> :   "لا" # ARABIC LIGATURE LAM WITH ALEF
<UFEF7> :   "لأ" # ARABIC LIGATURE LAM WITH ALEF WITH HAMZA ABOVE
<UFEF9> :   "لإ" # ARABIC LIGATURE LAM WITH ALEF WITH HAMZA BELOW
<UFEF5> :   "لآ" # ARABIC LIGATURE LAM WITH ALEF WITH MADDA ABOVE
....
Only, to the best of my understanding these are single unicode points,
specified in the Basic Multiligual Plane, within the Arabic
Presentation Forms-B (see
http://en.wikipedia.org/wiki/Basic_Multilingual_Plane). How would
this explain how to create a char made of a base and a combining
diacritic?

A number of times I found that this feature is needed. Fortunately, Unicode supports my language better than other languages and I don't need it for my own language. However, Unicode stopped with adding support for the rest of the languages and some of the features for my language don't have full support inside of Unicode. Fortunately, again, it is possible to use my language fully by combining regular features of XKB and keymap engines at other OS-es. At the other side, it is obviously that it is not enough for many other languages.

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.