Bug#241838: d-i Turkish keyboard issues
Dé Déar, 2004-04-01 ag 01:15 -0700, scríobh email@example.com:
> [My previous postings were probably blocked due to your spam
> configuration, so I am reposting from a different domain]
Sorry, it was my fault; I've been setting up spam filters and
evolution-1.5 from experimental; some mail got lost.
> Default Turkish keymap 'trq.kmap' doesn't fully work in bterm. I
> couldn't type Turkish spesific characters (all other non-turkish
> spesific ascii chars are okay). Though this is not a critical problem,
> I want to propose a solution. The problem stems from the fact that
> trq.kmap was not designed for UTF-8. There is another Turkish Q kmap
> --trqu.kmap for this purpose.
> I create a simple netboot iso with a modified console-data udeb which
> uses the trqu.kmap as default and it works at least in bterm (under
> C.UTF-8 locale). There is also a minor problem for this case.
> In the second console (Alt-F2) Turkish characters can be typed, but can
> not be properly displayed, since we don't have unifont where it exists
> in bterm frame buffer. But I could live with this problem.
> The real problem with this solution is that, I don't want to use UTF-8
> mode in virtual consoles after the installation is completed. There is
> a lot of problem in tr_TR.UTF-8 locale. Man files can't be properly
> displayed in UTF-8, readline has problems and the most important one,
> there are a few serious bugs in glibc.
> I couldn't perform a full d-i installation for some other d-i bugs, so
> couldn't test the whole case. Before submitting a patch, I want to
> know your suggestions. Is there a mechanism just to use Unicode keymap
> (trqu.kmap) for the early stages of d-i, but install the ISO keymap
> (trq.kmap) in the later stage. As you can see in the language-chooser
> module, we've already set the default locale as tr_TR which corresponds
> to tr_TR.ISO-8859-9 locale. If we install unicode trqu.kmap by default,
> it wouldn't work under this locale.
> As you may notice the keymap/fgGIod directory, there is another keyboard
> layout in Turkish, known as Turkish F. I would want to add it to
> kbd-chooser templates, but the same UTF-8 problem also exists here. So
> before creating a patch, we should solve the above problems.
> Hope I described the whole picture, let me know if you need additional
> info. Thanks for your help.
Ok, the best solution that appears to me is
(1) Change the default keyboard in kbd-chooser for Turkish to trqu.kmap.
(2) In kbd-chooser prebaseconfig, we can change the settings passed to
the second stage; I can add code there to change trqu -> trq for the
second stage. I will need to test this, though.