On Thu, Jun 30, 2022 at 08:06:05AM +0000, Riza Dindir wrote:
> Hello Thomas,
>
> When I change the kb layout using "setxkbmap -layout tr" and get the
> keyboard layout (with xkbprint...), I can see where the special
> characters will be. The locations for these are correct.
>
> But, after changing the keyboard layout to tr, when I press the
> "Scedilla" key it does not output anything on xterm (xterm -class
> UXTerm, or xterm -u8). But the key labeled "Iabovedot" does output the
> "i" character when pressed.
Each non-ASCII key that I tried last night was working.
But I started xterm using a UTF-8 encoding (via locale settings).
If you examine the right-mouse menu, you may see that xterm
is/is-not set to use UTF-8. Normally for UTF-8, the menu items
are selected and grayed-out.
>
> But on X applications, like firefox, I can, after changing the
> keyboard layout (to us, or de, or tr), all the keys produce the
> characters as expected.
>
> Riza
>
> On Thu, Jun 30, 2022 at 12:11 AM Thomas Dickey <dickey%his.com@localhost> wrote:
> >
> > On Wed, Jun 29, 2022 at 03:20:21PM -0400, Thomas Dickey wrote:
> > > On Wed, Jun 29, 2022 at 05:56:09PM +0200, Martin Husemann wrote:
> > > > On Wed, Jun 29, 2022 at 06:21:46PM +0000, Riza Dindir wrote:
> > > > > I also changed the font for XTerm in the Xresources file, which uses
> > > > > iso8859-9, but that does not do anything. Although the font changes,
> > > > > the characters for that language can not be entered on xterm.
> > > > >
> > > > > Is there a way to do that?
> > > >
> > > > You need to set the environment variable LC_CTYPE to e.g. de_DE.ISO8859-15
> > > > or de_DE.UTF-8 for german (the former giving you ISO 8859-15, the latter
> > > > UTF8 unicode encoding), or tr_TR.ISO8859-9 or tr_TR.UTF-8 for turkish.
> > > >
> > > > You can see all available locales in /usr/share/locale/.
> > >
> > > just
> > > locale -a
> >
> > But just "locale" shows what you are actually using.
> > On my test-account (not customized) for NetBSD 9.2,
> > the locale command shows this in uxterm:
> >
> > LANG=""
> > LC_CTYPE="en_US.UTF-8"
> > LC_COLLATE="C"
> > LC_TIME="C"
> > LC_NUMERIC="C"
> > LC_MONETARY="C"
> > LC_MESSAGES="C"
> > LC_ALL=""
> >
> > and this in xterm:
> >
> > LANG=""
> > LC_CTYPE="C"
> > LC_COLLATE="C"
> > LC_TIME="C"
> > LC_NUMERIC="C"
> > LC_MONETARY="C"
> > LC_MESSAGES="C"
> > LC_ALL=""
> >
> > Since (man locale...) LC_ALL and LANG do nothing when unset, the only
> > relevant setting for xterm is LC_CTYPE. The other settings are used by
> > other applications. For UTF-8 encoding, the country-code tr_TR versus
> > en_US.UTF-8 likewise does not matter. It would be relevant (to other
> > applications) if it were not UTF-8. xterm uses the locale environment
> > which is set outside to decide whether to use UTF-8 encoding. It's
> > possible to configure xterm to allow switching after startup, but most
> > users don't want or need that.
> >
> > If xterm were started like this:
> >
> > setenv LC_CTYPE en_US.UTF-8
> > xterm
> >
> > or
> >
> > setenv LC_ALL en_US.UTF-8
> > xterm
> >
> > then the two outputs (from uxterm and xterm) would be the same. The
> > display (using the bitmap font) looks the same with either uxterm or
> > xterm started with a locale tweak. Both, by the way, use a less
> > complete font than Debian packages for the same XLFD. You'll probably
> > be better off using TrueType with NetBSD.
> >
> > While answering this question, I set my locale as described above,
> > and the keyboard behaved as expected when using Turkish layout.
> > The keys (seen with "cat -v") matched the picture which I obtained
> > using these commands:
> >
> > setxkbmap -layout tr
> > xkbprint -color "${DISPLAY}" - | ps2pdf - > tr_keyboard_layout.pdf
> >
> > The "setlocale" manpage is usually the place to go to see how the locale
> > environment variables are used. Looking now, I see that NetBSD does
> > this in nls(7):
> >
> > The environment variable settings are queried by their priority
> > level in the following manner:
> > ...
> >
> > The Open Group expands on the environment variables here:
> >
> > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
> >
> > LANG
> > This variable shall determine the locale category for native
> > language, local customs, and coded character set in the absence
> > of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES,
> > LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables. This
> > can be used by applications to determine the language to use for
> > error messages and instructions, collating sequences, date
> > formats, and so on.
> > LC_ALL
> > This variable shall determine the values for all locale
> > categories. The value of the LC_ALL environment variable has
> > precedence over any of the other environment variables starting
> > with LC_ (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
> > LC_NUMERIC, LC_TIME) and the LANG environment variable.
> > LC_CTYPE
> > This variable shall determine the locale category for character
> > handling functions, such as tolower(), toupper(), and isalpha().
> > This environment variable determines the interpretation of
> > sequences of bytes of text data as characters (for example,
> > single as opposed to multi-byte characters), the classification
> > of characters (for example, alpha, digit, graph), and the
> > behavior of character classes. Additional semantics of this
> > variable, if any, are implementation-defined.
> >
> > --
> > Thomas E. Dickey <dickey%invisible-island.net@localhost>
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
--
Thomas E. Dickey <dickey%invisible-island.net@localhost>
https://invisible-island.net
ftp://ftp.invisible-island.net
Attachment:
signature.asc
Description: PGP signature