Created attachment 26768 [details] [review] Tibetan keymap Here is a patch to add a keymap for the tibetan script.
In xk-c layouts are organized on per-country code (using iso3166). What country code should I use for that layout? My understanding it would be cn (I could not find the code for Tibet). I am wrong?
> In xk-c layouts are organized on per-country code (using iso3166). When the layouts are country-based, yes. But this one is used both in Bhutan (BT) for Dzongkha and Tibet (a region of China, thus not ISO code) for Tibetan, that's why I named it after the script name (tibt). Political stuff put apart, it would still be quite odd to look for a tibetan keymap in the cn part.
It is not a problem to create a variant bt(tib) just including cn(tib), we can do that. Would it be fine? > Political stuff put apart, it would still be quite odd to look for a > tibetan keymap in the cn part. Well, as long as Tibet is not independent - we could offer only that. With all my personal sympathies to Tibetians. PS And you cannot image the scale of my gratitude for putting political stuff apart. No, seriously.
> It is not a problem to create a variant bt(tib) just including cn(tib), we can > do that. Mmm, that wouldn't really be a variant, but the main layout for bt, as dzongkha(dzo) is the main language there. The cn variant should probably be called after the Tibetan language iso code (bod). There could also be an in(lbj) variant for the Ladakhi language which also uses the Tibetan script. I'm still wondering whether these shouldn't just include a script-based tibt layout.
> Mmm, that wouldn't really be a variant, but the main layout for bt, as Oops, I just checked - the current bt layout is nearly exact copy of your code, so it will just stay as it is! > dzongkha(dzo) is the main language there. The cn variant should probably > be called after the Tibetan language iso code (bod). Fine! Since bt is already there, I'd just create cn(bod) by inclusion of bt(basic). > There could also be an in(lbj) variant for the Ladakhi language which > also uses the Tibetan script. Again, that makes sense. > I'm still wondering whether these shouldn't just include a script-based > tibt layout. I'd try to avoid script-based layouts, really. The only exceptions so far are latin and ara. Anyway, in GUI people are free to use country-based or language-based approach, so the actual physical name and location of the file should not matter, right?
> > Mmm, that wouldn't really be a variant, but the main layout for bt, as > Oops, I just checked - the current bt layout is nearly exact copy of your code, > so it will just stay as it is! Ooopss. I would however request the removal of > > I'm still wondering whether these shouldn't just include a script-based > > tibt layout. > I'd try to avoid script-based layouts, really. The only exceptions so far are > latin and ara. Well, the fact that I hadn't noticed the bt layout shows that they'd still be useful. The story is actually that a friend of mine was looking for a way to type Tibetan letters. I hadn't thought about looking for Bhutan layouts, and I hadn't looked in the cn variants either... > Anyway, in GUI people are free to use country-based or language-based approach, > so the actual physical name and location of the file should not matter, right? Once a bod variant is added to the cn layout that would probably be the case, right.
> Ooopss. I would however request the removal of ... what? > looking for a way to type Tibetan letters. I hadn't thought about > looking for Bhutan layouts, and I hadn't looked in the cn variants > either... Well, if you'd use the GUI tool, you'd look into Dzongkha section (per-language), right? > Once a bod variant is added to the cn layout that would probably be the > case, right. Ok, so let it be cn(bod) then, great!
> > Ooopss. I would however request the removal of > ... what? Oh, sorry, I used to have troubles with the right-alt binding, but after some tests the layout currently in place doesn't bring problems, but apparently I forgot to remove the sentence I hadn't finished. > > looking for a way to type Tibetan letters. I hadn't thought about > > looking for Bhutan layouts, and I hadn't looked in the cn variants > > either... > Well, if you'd use the GUI tool, you'd look into Dzongkha section > (per-language), right? Nope, because I wouldn't know that Dzongkha uses the Tibetan script as well. > > Once a bod variant is added to the cn layout that would probably be the > > case, right. > Ok, so let it be cn(bod) then, great! Yes.
One more question. I see in symbols/cn, there is cn(tib) and cn(tib_asciinum). Are they related in any way to the proposed cn(bod)?
> One more question. I see in symbols/cn, there is cn(tib) and cn(tib_asciinum). > Are they related in any way to the proposed cn(bod)? Oh, tib is indeed another iso code for Tibetan, it's probably better to leave it that way.
but cn(tib) is different from what you propose. Do you want 2 Tibetian variants? Or replace the existing? Or what?
> but cn(tib) is different from what you propose. Do you want 2 Tibetian > variants? Or replace the existing? Or what? What I proposed was probably just the Bhutan layout I guess (I had just found it on thdl.org). I guess we don't want to change what already exists in cn.
I am lost at that point. There are already proper bt(basic) and cn(tib). Should we close the bug as "fixed" or is something missing?
> I am lost at that point. Sorry for the confusion, I should have had a closer look before submitting the bug. > There are already proper bt(basic) and cn(tib). Should > we close the bug as "fixed" or is something missing? Well, it may be useful to have an in(lbj) layout, but I don't know whether the chines, the bhutanese or some other layout should be used. Concerning my own needs, the bug can be closed.
Ok, if some Indians complains, we reopen that bug. For a moment, closing it. > I should have had a closer look before submitting the bug. No hard feelings;)
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.