Hi Fedora users,
I'm using US International keyboard but i can't type (cedilla). ' + c = ć ????? How can i fix this?
Regards, Cris Amon
______________________________________________________________________
Yahoo! Mail: 6MB, anti-spam e antivírus gratuito! Crie sua conta agora: http://mail.yahoo.com.br
I've had that problem ever since RH8 (I think).
In some circumstances, the proper character is written, but gtk widgets and mozilla don't seem capable.
I think that the wrong character is being used ever since the move to UTF-8, but I can't find which is which.
On Sun, 2003-11-30 at 20:09, Cris Amon Rocha wrote:
Hi Fedora users,
I'm using US International keyboard but i can't type (cedilla). ' + c = ć ????? How can i fix this?
Regards, Cris Amon
On Nov 30, 2003, Rui Miguel Seabra rms@1407.org wrote:
I've had that problem ever since RH8 (I think). In some circumstances, the proper character is written, but gtk widgets and mozilla don't seem capable.
I think that the wrong character is being used ever since the move to UTF-8, but I can't find which is which.
Why would anyone expect ' c to generate something different from ć? Sure enough, we used to abuse it to generate ç, but with an international configuration, since there are languages that do use ć, they have to get preference for the obvious meaning of ć. So we, poor users of ç (or any other ¸s) have to use Compose (generally the right Alt key), comma and the letter under which the Cedilla character should be placed. Worksforme, at least in Fedora Core 1. I vaguely remember that it worked in RHL9 as well, and possibly even on 8.0. If you want the gory details, there are bugzilla reports about this, but I don't have the bug numbers handy.
Well, I just "fixed" it here on my box. Here's what I did: I replaced this
SUPPORTED="en_US.UTF-8:en_US:en:pt_BR.UTF-8:pt_BR:pt"
for this
SUPPORTED="en_US.iso88591:en_US:en:pt_BR.iso88591:pt_BR:pt"
Now all seems to work just fine (of course, I lost UTF-8 support, but that doesn't seem to be a probl at the moment).
HTH
Andre
On 01 Dec 2003 11:27:47 -0200 Alexandre Oliva aoliva@redhat.com wrote:
On Nov 30, 2003, Rui Miguel Seabra rms@1407.org wrote:
I've had that problem ever since RH8 (I think). In some circumstances, the proper character is written, but gtk widgets and mozilla don't seem capable.
I think that the wrong character is being used ever since the move to UTF-8, but I can't find which is which.
Why would anyone expect ' c to generate something different from __? Sure enough, we used to abuse it to generate ç, but with an international configuration, since there are languages that do use __, they have to get preference for the obvious meaning of __. So we, poor users of ç (or any other ¸s) have to use Compose (generally the right Alt key), comma and the letter under which the Cedilla character should be placed. Worksforme, at least in Fedora Core 1. I vaguely remember that it worked in RHL9 as well, and possibly even on 8.0. If you want the gory details, there are bugzilla reports about this, but I don't have the bug numbers handy.
-- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
On Dec 1, 2003, Andre Costa acosta@ar.microlink.com.br wrote:
Now all seems to work just fine (of course, I lost UTF-8 support, but that doesn't seem to be a probl at the moment).
Note that switching to a non-UTF-8 environment doesn't make you exempt from the requirement that filenames in ext[23] must be in UTF-8 form. I don't know what kind of problems you can run into for not meeting this requirement.
Argh! ={ Didn't think about it... well, I usually don't use accents on file names, but this of course doesn't mean I won't run into probls.
So, the conclusion is that UTF-8 support for i18n still needs a lot of work to correctly support some Latin languages (at least Portuguese and Spanish, from what I've been reading on this forum). Or am I missing something?
Does anyone here knows if using ISO-8859-1 as default locale (instead of UTF-8) is dangerous in anyway to ext[23]?
Best,
Andre
On 01 Dec 2003 13:22:47 -0200 Alexandre Oliva aoliva@redhat.com wrote:
On Dec 1, 2003, Andre Costa acosta@ar.microlink.com.br wrote:
Now all seems to work just fine (of course, I lost UTF-8 support, but that doesn't seem to be a probl at the moment).
Note that switching to a non-UTF-8 environment doesn't make you exempt from the requirement that filenames in ext[23] must be in UTF-8 form. I don't know what kind of problems you can run into for not meeting this requirement.
-- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer
On Mon, 2003-12-01 at 08:27, Alexandre Oliva wrote:
On Nov 30, 2003, Rui Miguel Seabra rms@1407.org wrote:
I've had that problem ever since RH8 (I think). In some circumstances, the proper character is written, but gtk widgets and mozilla don't seem capable.
I think that the wrong character is being used ever since the move to UTF-8, but I can't find which is which.
Why would anyone expect ' c to generate something different from ć? Sure enough, we used to abuse it to generate ç, but with an international configuration, since there are languages that do use ć, they have to get preference for the obvious meaning of ć. So we, poor users of ç (or any other ¸s) have to use Compose (generally the right Alt key), comma and the letter under which the Cedilla character should be placed. Worksforme, at least in Fedora Core 1. I vaguely remember that it worked in RHL9 as well, and possibly even on 8.0. If you want the gory details, there are bugzilla reports about this, but I don't have the bug numbers handy.
Right, but actually we did add some conveniences recently for users who don't need ć but do need ç:
* If your LC_CTYPE points to a language that uses the cedilla (pt, fr, tr, etc.), then GTK+ will by default use the 'imcedilla' input method which differs from the default input method only in the matter of the this compose sequence.
So, put LC_CTYPE=pt_BR.UTF-8 in your /etc/sysconfig/i18n or ~/.i18n. This does not affect the language of the user interface.
(If your are running with LANG=pt_BR.UTF-8, then LC_CTYPE is automatically set appropriately, of course.)
* You can also manually force the the choice of input method by setting then environment variable GTK_IM_MODULE to 'imcedilla'.
Regards, Owen
On Dec 1, 2003, Andre Costa acosta@ar.microlink.com.br wrote:
So, the conclusion is that UTF-8 support for i18n still needs a lot of work to correctly support some Latin languages
Err... What are the facts you're using to support this conclusion? I've used UTF-8 without major issues other than those at the transition point since RHL8.0. Have you read the Release Notes about UTF-8, by any chance?
Sorry, I didn't mean it to sound as bad as it did, it definitely doesn't need "a lot" of work -- but it could be easier. After all, I chose Brazilian Portuguese support, UTF-8 support and ISO-8859-1 support during installation.
Since RH8 I've always had to do some workarounds so that I could properly use Portuguese accents (YMMV since you obviously also use such accents, since you're Brazilian as well ;)).
So, to be fair (and I have been on my original msg ;)), I might be missing something -- and I wouldn't be surprised if I was. How do you deal with UTF-8 + Brazilian Portuguese + X11 + vim etc.?
BTW: I hadn't read release notes, thks for the pointer. However, this was not a pleasant read at all:
"The input of non-ASCII characters from the system console is not possible; only graphical applications support the input of these characters." --> this was exactly what I was experiencing with console vim
"Filenames located on ext3 file systems should be in UTF-8." --> this is what you were referring to
Even if I switch to gvim (assuming it handles UTF-8 nicely), it might not solve the problem, because I was experiencing probls with gaim, for example ('ç' appeared as 'c-grave' or something like this).
I would really appreciate some guidance here... ;)
TIA
Andre
On 01 Dec 2003 15:37:57 -0200 Alexandre Oliva aoliva@redhat.com wrote:
On Dec 1, 2003, Andre Costa acosta@ar.microlink.com.br wrote:
So, the conclusion is that UTF-8 support for i18n still needs a lot of work to correctly support some Latin languages
Err... What are the facts you're using to support this conclusion? I've used UTF-8 without major issues other than those at the transition point since RHL8.0. Have you read the Release Notes about UTF-8, by any chance?
-- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer
Hi Owen,
On Mon, 01 Dec 2003 12:10:32 -0500 Owen Taylor otaylor@redhat.com wrote:
Right, but actually we did add some conveniences recently for users who don't need __ but do need ç:
If your LC_CTYPE points to a language that uses the cedilla (pt, fr, tr, etc.), then GTK+ will by default use the 'imcedilla' input method which differs from the default input method only in the matter of the this compose sequence.
So, put LC_CTYPE=pt_BR.UTF-8 in your /etc/sysconfig/i18n or ~/.i18n. This does not affect the language of the user interface.
(If your are running with LANG=pt_BR.UTF-8, then LC_CTYPE is automatically set appropriately, of course.)
You can also manually force the the choice of input method by
setting then environment variable GTK_IM_MODULE to 'imcedilla'.
I tried putting LC_CTYPE=pt_BR.UTF-8 on /etc/sysconfig/i18n, but it did not work: 'ç' still appeared as 'c-grave' on sylpheed (GTK 1.2 app) -- and I did even set GTK_IM_MODULE to imcedilla.
Any idea of what could be the probl? Also, what could be the probl of creating an ISO-8859-1 filename on ext3? Only unreadable names or something worse?
TIA
Andre
On Mon, 2003-12-01 at 13:45, Andre Costa wrote:
Hi Owen,
On Mon, 01 Dec 2003 12:10:32 -0500 Owen Taylor otaylor@redhat.com wrote:
Right, but actually we did add some conveniences recently for users who don't need __ but do need ç:
If your LC_CTYPE points to a language that uses the cedilla (pt, fr, tr, etc.), then GTK+ will by default use the 'imcedilla' input method which differs from the default input method only in the matter of the this compose sequence.
So, put LC_CTYPE=pt_BR.UTF-8 in your /etc/sysconfig/i18n or ~/.i18n. This does not affect the language of the user interface.
(If your are running with LANG=pt_BR.UTF-8, then LC_CTYPE is automatically set appropriately, of course.)
You can also manually force the the choice of input method by
setting then environment variable GTK_IM_MODULE to 'imcedilla'.
I tried putting LC_CTYPE=pt_BR.UTF-8 on /etc/sysconfig/i18n, but it did not work: 'ç' still appeared as 'c-grave' on sylpheed (GTK 1.2 app) --
^^^^^^^^^^^
The above only refers to GTK+-2.x apps. For apps using the X compose tables, that's out of my hands. I think the development versions of XFree86 have switched the sequence to give ç in all locales, which (IMO) isn't really right, but should be better for many users.
(/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose could be edited for a short-term fix.)
Regards. Owen
On Mon, 01 Dec 2003 15:40:16 -0500 Owen Taylor otaylor@redhat.com wrote:
[...]
The above only refers to GTK+-2.x apps. For apps using the X compose tables, that's out of my hands. I think the development versions of XFree86 have switched the sequence to give ç in all locales, which (IMO) isn't really right, but should be better for many users.
(/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose could be edited for a short-term fix.)
Thks, I will give it a try.
Best,
Andre
On Dec 1, 2003, Andre Costa acosta@ar.microlink.com.br wrote:
So, to be fair (and I have been on my original msg ;)), I might be missing something -- and I wouldn't be surprised if I was. How do you deal with UTF-8 + Brazilian Portuguese + X11 + vim etc.?
I use us_intl as my keyboard configuration (since I don't have any ABNT2 keyboards :-), and use Compose comma c to generate ç. This works in all applications I've tried, both text applications started from within gnome-terminal and graphical applications.
"The input of non-ASCII characters from the system console is not possible; only graphical applications support the input of these characters."
--> this was exactly what I was experiencing with console vim
'fraid I can't help with this one. Certainly the X11 configuration won't make any difference here.
Even if I switch to gvim (assuming it handles UTF-8 nicely), it might not solve the problem, because I was experiencing probls with gaim, for example ('ç' appeared as 'c-grave' or something like this).
I haven't tried gaim. I use xchat, and it works for me, even though the IRC protocol didn't define a standard encoding or some mechanism to communicate the encoding last I looked.
On Mon, 2003-12-01 at 13:27, Alexandre Oliva wrote:
On Nov 30, 2003, Rui Miguel Seabra rms@1407.org wrote:
I've had that problem ever since RH8 (I think). In some circumstances, the proper character is written, but gtk widgets and mozilla don't seem capable.
I think that the wrong character is being used ever since the move to UTF-8, but I can't find which is which.
Why would anyone expect ' c to generate something different from ć? Sure enough, we used to abuse it to generate ç, but with an international configuration, since there are languages that do use ć, they have to get preference for the obvious meaning of ć. So we, poor users of ç (or any other ¸s) have to use Compose (generally the right Alt key), comma and the letter under which the Cedilla character should be placed. Worksforme, at least in Fedora Core 1.
That's what I use, with near total failure.
Rui
Thank you for your tips, Owen.
However, it is a bit weird to get ç by typing "' c2" I don't mind, it's just a matter of habit, but I preferred the older way "AltGr+comma c" :)
Any suggestion on how to change this?
Once again thank you,
Rui
On Mon, 2003-12-01 at 16:31, Andre Costa wrote:
So, the conclusion is that UTF-8 support for i18n still needs a lot of work to correctly support some Latin languages (at least Portuguese and Spanish, from what I've been reading on this forum). Or am I missing something?
From a Portuguese standing point of view, you must be missing something ;)
The pt keyboard works perfectly fine. us_intl is not designed for normal pt keyboards but for people who prefer the us keyboard (better for programming for instance) but would like access to international characters like á and ç :)
Hugs, Rui
On Dec 2, 2003, Rui Miguel Seabra rms@1407.org wrote:
That's what I use, with near total failure.
Hmm... Interesting. I hadn't realized it failed in GTK2 apps such as gnome-terminal (I'd never tried to emit accented characters in a command line terminal, let alone ç). ç works in GNU Emacs and Mozilla, where I do all of my e-mail and text composition. It's probably the GTK2 issue that Owen mentioned.
It's too bad that GTK2 uses its own key composition mechanism, totally unrelated with the maps used by X.
On Dec 2, 2003, Alexandre Oliva aoliva@redhat.com wrote:
On Dec 2, 2003, Rui Miguel Seabra rms@1407.org wrote:
That's what I use, with near total failure.
Hmm... Interesting. I hadn't realized it failed in GTK2 apps such as gnome-terminal
But then, a few seconds later, it works on the same gnome-terminal, and I haven't changed anything. How very odd!
-
Alexandre Oliva -
Alexandre Oliva -
Andre Costa -
Cris Amon Rocha -
Owen Taylor -
Rui Miguel Silva Seabra