i18n-bugs May 2010

i18n-bugs@lists.fedoraproject.org

2 participants
438 discussions

[Fedora-i18n-bugs] [Bug 578019] New: lang-specific overrides rule doesn't work as expected
by Red Hat Bugzilla 29 Jun '10

29 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: lang-specific overrides rule doesn't work as expected https://bugzilla.redhat.com/show_bug.cgi?id=578019 Summary: lang-specific overrides rule doesn't work as expected Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: hanazono-fonts AssignedTo: tagoh(a)redhat.com ReportedBy: tagoh(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: tagoh(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org Depends on: 578015 Blocks: 507684 Estimated Hours: 0.0 Classification: Fedora Target Release: --- Description of problem: All of detailed information is available on my post at the fonts list: http://lists.fedoraproject.org/pipermail/fonts/2010-March/001117.html binding="same" in the fontconfig config file prevents to apply the rule for the specific language only properly. As a result, fonts is used for non-targetted languages and it may gives different look and feel in some cases. I'd propose to get rid of binding="same" from: 66-hanazono.conf -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 9

[Fedora-i18n-bugs] [Bug 578018] New: lang-specific overrides rule doesn't work as expected
by Red Hat Bugzilla 29 Jun '10

29 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: lang-specific overrides rule doesn't work as expected https://bugzilla.redhat.com/show_bug.cgi?id=578018 Summary: lang-specific overrides rule doesn't work as expected Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: culmus-fonts AssignedTo: psatpute(a)redhat.com ReportedBy: tagoh(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Depends on: 578015 Blocks: 507684 Estimated Hours: 0.0 Classification: Fedora Target Release: --- Description of problem: All of detailed information is available on my post at the fonts list: http://lists.fedoraproject.org/pipermail/fonts/2010-March/001117.html binding="same" in the fontconfig config file prevents to apply the rule for the specific language only properly. As a result, fonts is used for non-targetted languages and it may gives different look and feel in some cases. I'd propose to get rid of binding="same" from: 65-culmus-aharoni-clm.conf 65-culmus-david-clm.conf 65-culmus-drugulin-clm.conf 65-culmus-ellinia-clm.conf 65-culmus-frank-ruehl-clm.conf 65-culmus-miriam-clm.conf 65-culmus-miriam-mono-clm.conf 65-culmus-nachlieli-clm.conf -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 12

[Fedora-i18n-bugs] [Bug 578017] New: lang-specific overrides rule doesn't work as expected
by Red Hat Bugzilla 29 Jun '10

29 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: lang-specific overrides rule doesn't work as expected https://bugzilla.redhat.com/show_bug.cgi?id=578017 Summary: lang-specific overrides rule doesn't work as expected Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: baekmuk-ttf-fonts AssignedTo: cchance(a)redhat.com ReportedBy: tagoh(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, cchance(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org Depends on: 578015 Blocks: 507684 Estimated Hours: 0.0 Classification: Fedora Target Release: --- Description of problem: All of detailed information is available on my post at the fonts list: http://lists.fedoraproject.org/pipermail/fonts/2010-March/001117.html binding="same" in the fontconfig config file prevents to apply the rule for the specific language only properly. As a result, fonts is used for non-targetted languages and it may gives different look and feel in some cases. I'd propose to get rid of binding="same" from: 65-baekmuk-ttf-batang.conf 65-baekmuk-ttf-dotum.conf 65-baekmuk-ttf-gulim.conf -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 10

[Fedora-i18n-bugs] [Bug 575433] New: [abrt] crash in imsettings-0.107.4-7.fc12: Process /usr/libexec/im-settings-daemon was killed by signal 11 (SIGSEGV)
by Red Hat Bugzilla 28 Jun '10

28 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] crash in imsettings-0.107.4-7.fc12: Process /usr/libexec/im-settings-daemon was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=575433 Summary: [abrt] crash in imsettings-0.107.4-7.fc12: Process /usr/libexec/im-settings-daemon was killed by signal 11 (SIGSEGV) Product: Fedora Version: 12 Platform: i686 OS/Version: Linux Status: NEW Status Whiteboard: abrt_hash:7a875ae3b25bf9f981dfca447533aba6b76eaa10 Severity: medium Priority: low Component: imsettings AssignedTo: tagoh(a)redhat.com ReportedBy: tears_of_time(a)ukr.net QAContact: extras-qa(a)fedoraproject.org CC: tagoh(a)redhat.com, fedora-i18n-bugs(a)redhat.com Estimated Hours: 0.0 Classification: Fedora abrt 1.0.8 detected a crash. architecture: i686 Attached file: backtrace cmdline: /usr/libexec/im-settings-daemon component: imsettings executable: /usr/libexec/im-settings-daemon kernel: 2.6.32.9-70.fc12.i686.PAE package: imsettings-0.107.4-7.fc12 rating: 4 reason: Process /usr/libexec/im-settings-daemon was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 5

[Fedora-i18n-bugs] [Bug 579413] New: [abrt] crash detected in imsettings-0.107.4-2.fc12
by Red Hat Bugzilla 28 Jun '10

28 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] crash detected in imsettings-0.107.4-2.fc12 https://bugzilla.redhat.com/show_bug.cgi?id=579413 Summary: [abrt] crash detected in imsettings-0.107.4-2.fc12 Product: Fedora Version: 12 Platform: i686 OS/Version: Linux Status: NEW Status Whiteboard: abrt_hash:085ded5f613570c2f05059bbb37943c2751da840 Severity: medium Priority: low Component: imsettings AssignedTo: tagoh(a)redhat.com ReportedBy: optimal_solution2000(a)yahoo.com QAContact: extras-qa(a)fedoraproject.org CC: tagoh(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Estimated Hours: 0.0 Classification: Fedora abrt detected a crash. Attached file: backtrace cmdline: /usr/libexec/im-settings-daemon component: imsettings executable: /usr/libexec/im-settings-daemon kernel: 2.6.31.5-127.fc12.i686.PAE package: imsettings-0.107.4-2.fc12 rating: 4 reason: Process was terminated by signal 11 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Fedora-i18n-bugs] [Bug 545712] New: String error in ibus po file
by Red Hat Bugzilla 27 Jun '10

27 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: String error in ibus po file https://bugzilla.redhat.com/show_bug.cgi?id=545712 Summary: String error in ibus po file Product: Fedora Version: 12 Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: ibus AssignedTo: phuang(a)redhat.com ReportedBy: apeter(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: phuang(a)redhat.com, fedora-i18n-bugs(a)redhat.com Estimated Hours: 0.0 Classification: Fedora Target Release: --- Description of problem: The string #3 in ibus po file says: "Copyright (c) 2007-2009 Peng Huang\n Copying (c) 2007-2009 Red Hat, Inc." I guess the second line should also be "Copyright" instead of "Copying". -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Fedora-i18n-bugs] [Bug 586306] New: Improve fontconfig config file
by Red Hat Bugzilla 25 Jun '10

25 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Improve fontconfig config file https://bugzilla.redhat.com/show_bug.cgi?id=586306 Summary: Improve fontconfig config file Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: baekmuk-ttf-fonts AssignedTo: cchance(a)redhat.com ReportedBy: tagoh(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, cchance(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Target Release: --- Description of problem: According to the testing result of Bug#578017, it needs to be improved to get things working efficiently for Korean desktop. Version-Release number of selected component (if applicable): baekmuk-ttf-*-fonts-2.2-25.fc13.noarch How reproducible: always Steps to Reproduce: 1.fc-match monospace:lang=ko-kr or sans:lang=ko-kr or serif:lang=ko-kr 2. 3. Actual results: depends on what kind of fonts are installed. Expected results: Baekmuk Gulim for monospace, Baekmuk Dotum for sans-serif and Baekmuk Batang for serif should be displayed. Additional info: See https://bugzilla.redhat.com/show_bug.cgi?id=578017#c4 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Fedora-i18n-bugs] [Bug 597305] New: need xinput conf file for XIM to enable X locale compose maps
by Red Hat Bugzilla 25 Jun '10

25 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: need xinput conf file for XIM to enable X locale compose maps https://bugzilla.redhat.com/show_bug.cgi?id=597305 Summary: need xinput conf file for XIM to enable X locale compose maps Product: Red Hat Enterprise Linux 6 Version: 6.0 Platform: All OS/Version: Linux Status: NEW Keywords: Reopened Severity: medium Priority: high Component: imsettings AssignedTo: tagoh(a)redhat.com ReportedBy: mchehab(a)redhat.com QAContact: desktop-bugs(a)redhat.com CC: jrb(a)redhat.com, tagoh(a)redhat.com, petersen(a)redhat.com, eng-i18n-bugs(a)redhat.com, marcus(a)sbh.eng.br, mclasen(a)redhat.com, kevin(a)tigcc.ticalc.org, rodrigopadula(a)projetofedora.org, rafael.espindola(a)gmail.com, vcrhonek(a)redhat.com, allisson(a)gmail.com, ehabkost(a)redhat.com, dchen(a)redhat.com, peter.hutterer(a)redhat.com, brunojcm(a)gmail.com, i18n-bugs(a)lists.fedoraproject.org, rosset.filipe(a)gmail.com, myllynen(a)redhat.com, awilliam(a)redhat.com Depends on: 505100 Blocks: 473302 Classification: Red Hat Target Release: --- Clone Of: 505100 +++ This bug was initially created as a clone of Bug #505100 +++ I'm noticing this bug after upgrading my desktop to RHEL6. Description of problem: We have a problem with the keyboard Us Internacional. I'm using Fedora 11 in pt_BR Looking the file /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz, I found this: compose '\'' 'C' to 'Ç' compose '\'' 'c' to 'ç' This is correct, but, when I press ' + c or ' + C = ć or Ć. In portuguese we don't have acent in the c, the correct is ç (C + cedilla) Version-Release number of selected component (if applicable): rpm -qf /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz The package is kbd-1.15-7.fc11.i586 How reproducible: Choose the pt_BR locale and the US ACENTOS(US International) keyboard layout Actual results: when I press ' + c or ' + C = ć or Ć. Expected results: ç (C + cedilla) Additional info: > Use [RAlt]+[,] and [c] to get ç. > > Kevin Kofler > It works, but we can't change the default way to use the us_acentos(US International) keyboard. Since Fedora 1 and in all others OS like windows and others distros when we choose the pt_BR language and the US Internacional keyboard when we press C + ' we have = ç --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-06-10 20:08:53 EDT --- As I wrote in my mail, this is a feature. The US International layout supports many languages, including languages which do have a ć. The whole point is to be INTERNATIONAL. Making the layout behave differently based on the system locale makes no sense at all. --- Additional comment from ehabkost(a)redhat.com on 2009-06-10 20:43:42 EDT --- The point of localization is to make the system more accessible to people from different countries. The way people type "ç" in Brazil is typing the ['] key and then [c]. Asking the user to use a different method is like asking the user to switch to a different keyboard layout. I would say that in practice, we use a different keyboard layout, even if the labels on the physical keyboard look the same. I don't know how this can be implemented in the end (maybe it is already implemented using some layout variation and I don't know it), but this is an essential feature for making Fedora acessible for the brazilian audience. If this is not considered a bug, then consider this a feature request, then. --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-06-10 20:59:36 EDT --- There needs to be a us-brazil or something layout then. Redefining us-intl based on locale is a bad idea. --- Additional comment from vcrhonek(a)redhat.com on 2009-06-11 08:06:16 EDT --- E. g. the letter 'č' is used in Czech Republic (and no other accent with 'c'). It's not possible to have everything included in one keymap. There are four Brazilian keymaps in /lib/kbd/keymaps/i386/qwerty, please use one of them. --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-06-11 14:49:56 EDT --- >From http://en.wikipedia.org/wiki/Ć: "It is the fifth letter of: Polish, Sorbian, Croatian, and Bosnian alphabets, as well as the Latin forms of Serbian, and Macedonian (in some forms)[1]. It is fourth in the Belarusian Łacinka alphabet." --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-06-11 15:57:41 EDT --- The question is: Since Fedora 1 to Fedora 9, when we press c + ' we had = ç This is the default way in pt_BR locale with US International keyboard to do it in Windows, Solaris, Mac/OS and all Linux distributions, including Fedora 1 to 9! We are receiving a lot of claims in Brasil since Fedora 9 about this! We can't force the users to change the default way to use the keyboard. This is a big usability problem for Brazilians. Fedora is used by many governments departments, companies and schools. We can't force this users to change the way to write or to buy new keyboards. --- Additional comment from ehabkost(a)redhat.com on 2009-06-15 10:42:10 EDT --- (In reply to comment #4) > > There are four Brazilian keymaps in /lib/kbd/keymaps/i386/qwerty, please use > one of them. I didn't test it, but it looks like the br-latin1-us keymap is what I was looking for (a US layout keymap with deadkeys for brazilian audience). I don't know about the issues Rodrigo is seeing, however. Maybe there is a problem somewhere else, or Rodrigo expects Anaconda to display those layouts as options at install time. It isn't very clear to me what configuration options he tried, and what exactly is not working for him. --- Additional comment from vcrhonek(a)redhat.com on 2009-06-15 11:36:50 EDT --- Rodrigo, do you talk about text console, right? Because kbd contains only text console stuff, not stuff used with X server... "loadkeys /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz" and typing "' + c" produced "ç" for me in _text console_. Typing the same with "USA International (with dead keys)" produced "ć" in _gnome-terminal_. System locale doesn't matter. --- Additional comment from petersen(a)redhat.com on 2009-06-17 03:19:13 EDT --- If this is a issue in gtk apps then I suggest trying to install the gtk-immodules package, which includes the cedilla immodule - no longer installed by default in F11 gtk2. --- Additional comment from brunojcm(a)gmail.com on 2009-06-17 19:59:50 EDT --- I'm using Fedora 11 and having the same problem with ç. I think it's not correct to say that's not a bug, because people in Brazil always use ' + c to put the ç. It's true that running 'loadkeys /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz' or 'loadkeys /lib/kbd/keymaps/i386/qwerty/br-latin1-us.map.gz' makes ' + c put a ç in _text console_, as says Vitezlav, but ã is not working on these keymaps. I think it's a really big mistake not installing gtk2-immodules by default, because we can hold on without ç in text console, but in gnome it's infeasible. I needed to install this package, edit /etc/X11/xinit/xinput.d/none.conf to use the cedilla im and include "en" on the cedilla line of /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to get ç working properly on gnome. What package can I fill a bug against? --- Additional comment from vcrhonek(a)redhat.com on 2009-06-18 02:20:41 EDT --- (In reply to comment #10) > I'm using Fedora 11 and having the same problem with ç. I think it's not > correct to say that's not a bug, because people in Brazil always use ' + c to > put the ç. > > It's true that running 'loadkeys > /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz' or 'loadkeys > /lib/kbd/keymaps/i386/qwerty/br-latin1-us.map.gz' makes ' + c put a ç in _text > console_, as says Vitezlav, but ã is not working on these keymaps. If 'ã' should work in Brazilian keymaps (i. e. not in us-acentos;)), please fill a new bug and we should fix it with kbd upstream. > > I think it's a really big mistake not installing gtk2-immodules by default, > because we can hold on without ç in text console, but in gnome it's infeasible. > I needed to install this package, edit /etc/X11/xinit/xinput.d/none.conf to use > the cedilla im and include "en" on the cedilla line of > /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to get ç working properly on > gnome. > What package can I fill a bug against? I'll change component to xkeyboard-config - keymaps in X generally, that's probably it. If not, feel free to reassign it accordingly. --- Additional comment from petersen(a)redhat.com on 2009-06-18 19:50:20 EDT --- Do you have a Brazilian or US keyboard? If you login to your desktop after choosing one of the Brazilian keyboards in the GDM keyboard menu, it does not work for you? --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-06-18 22:30:28 EDT --- I'm using US keyboard + pt_br language in my system! Since fedora 1 and in all OS with pt_BR support, when whe choose the pt_BR language and US International Keyboard(US Acentos) when we press ' + c we have = ç but it isn't happen using fedora 10 and 11. The keyboard and language was defined during the Fedora 10 and 11 installations and re-seted after the installation, the problem persist in text and GUI modes. --- Additional comment from dchen(a)redhat.com on 2009-06-19 02:48:50 EDT --- Rodrigo, What you actually need is a Brazilian input method, which, as Jens points out, in gtk2-immodules. You may also need to install gtk2-immodules-xim, if there is no Qt equivalent. Previous Fedora works because they install gtk2-immodules for you. Keyboard guru Peter mentioned a simple rule: If the character does not print on your keyboard, or not the place you want, use an input method. --- Additional comment from brunojcm(a)gmail.com on 2009-06-23 13:17:36 EDT --- Can I report a bug against gtk2-immodules asking for installing it by default? It is really surprising that the same method of putting ç, which works in all other versions of fedora and other OS'es not working out of the box in Fedora 11. I think it's really inhibiting people to use Fedora 11 in Brazil. --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-07-05 22:42:26 EDT --- So, we need to install gtk2-immodules and gtk2-immodules-xim by default. We are receiving a lot of claims about this problem in the Brazilian lists and Forum. How we can add this packages by default as a dependency of a keyboard/localization package ? It's very important to be corrected ASAP. --- Additional comment from petersen(a)redhat.com on 2009-07-08 00:58:52 EDT --- (In reply to comment #16) > So, we need to install gtk2-immodules and gtk2-immodules-xim by default. gtk2-immodules-xim is not needed. > We are receiving a lot of claims about this problem in the Brazilian lists and > Forum. But can't you see im-cedilla.so (from gtk2-immodules) is gtk specific so it won't work consistently across the distro, eg in KDE, etc. Sorry, it does not seem to be the Right solution I am afraid but looks more like a hack. You didn't answer the question about trying to use a Brazilian layout instead of US International. Could you please try that at least from gdm login and report your experience? --- Additional comment from ehabkost(a)redhat.com on 2009-07-08 09:59:48 EDT --- (In reply to comment #17) > > You didn't answer the question about trying to use a Brazilian > layout instead of US International. Could you please try > that at least from gdm login and report your experience? I don't think there is a keyboard layout on the list that is equivalent to us-international + cedilla (that is what brazilian user expect when they have a US keyboard), but I still need to check the keyboard layout list, just in case. On my Fedora 10 machine I configured KDE to use '-layout us -variant alt-intl', and cedilla is working as expected. I don't know if there is an option for this on Anaconda or GDM, though. --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-07-09 12:29:40 EDT --- After the gtk2-immodules installation is necessary to change the file /etc/X11/xinit/xinput.d/none.conf Line: GTK_IM_MODULE=gtk-im-context-simple To: GTK_IM_MODULE=gtk-im-cedilla --- Additional comment from brunojcm(a)gmail.com on 2009-07-09 12:50:25 EDT --- Here I'm using a US keyboard and need cedilla. I tried all formats of "System > Preferences > Keyboard > Layout" without success. None of the "Brazil" variants matches the US international layout and if I choose "United States" there is not a variant that gives me the cedilla behaviour. The only way I could make it work was selecting "United States", variant "USA Alternative international (former us_intl)", and installing de gtk2-immodules and editing /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to put ":en" on the end of cedilla line. I agree with Eduardo, there is not a keyboard layout on the list that is equivalent to "US International + cedilla". I have a Windows VM on this Fedora and just select Language "Português (Brazil)", layout "United States (International)" and everything is working properly. PS. I have another issue here: When I press " two times, i get ¨ instead of "". When a press ' two times, i got a ´ instead of ''. It's not the desired behaviour, but I'm not sure it's layout fault. Thanks for all! --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-07-09 13:01:45 EDT --- Re your PS, that's also a feature. --- Additional comment from ehabkost(a)redhat.com on 2009-07-09 13:23:46 EDT --- (In reply to comment #20) > > PS. I have another issue here: When I press " two times, i get ¨ instead of "". > When a press ' two times, i got a ´ instead of ''. It's not the desired > behaviour, but I'm not sure it's layout fault. I think this is the expected behaviour. Press ['] two times, to get: ´ Press ['] then spacebar, to get: ' Press ["] two times, to get: ¨ Press ["] then spacebar, to get: " I think it always worked that way, didn't it? --- Additional comment from brunojcm(a)gmail.com on 2009-07-09 14:44:53 EDT --- (In reply to comment #22) > I think this is the expected behaviour. > > Press ['] two times, to get: ´ > Press ['] then spacebar, to get: ' > Press ["] two times, to get: ¨ > Press ["] then spacebar, to get: " > > I think it always worked that way, didn't it? I'm not sure about this because it's the first time I use Fedora with US keyboard.. all my others boxes have a brazilian ABNT2 keyboard, with works very well with the Brazilian layout. It would be more useful if the behaviour was like I described above in a new "Brazilian US International Keyboard" likely layout, because here in Brazil we don't use [¨] and [´] frequently, and it would seems more with Windows behaviour, users could feel less strange on migrations, etc. But I think it's a little off-topic, the real problem in Brazil is actually the cedilla, not it. Thanks for all! --- Additional comment from dchen(a)redhat.com on 2009-07-09 20:30:39 EDT --- Rodrigo, Modifying default behaviour of none.conf may upset other people that use it. It looks like Vitezslav is going to help you by providing a Brazilian keyboard layout/map for kbd and X. How about, as he said, open another bug so he can work on that? Alternatively, you can make an Brazilian input method for IBus. :-) --- Additional comment from tagoh(a)redhat.com on 2009-07-09 21:01:30 EDT --- Created an attachment (id=351200) --> (https://bugzilla.redhat.com/attachment.cgi?id=351200) im-cedilla.conf Just a suggestion if using cedilla immodule in gtk+ is a solution: How about put im-cedilla.so to the separate package like gtk-immodules-cedilla with the attached imsettings configuration file? you could update comps to require that package for Brazilian Portuguese Language Support then. although you need to choose that with im-chooser manually and need a bit updates on imsettings to support immodule only configuration. As Ding suggested, supporting cedilla in IBus may be the right way to go. we can enable IM for pt_BR and no need to do something with im-chooser basically then. Anyway, just for an idea. --- Additional comment from petersen(a)redhat.com on 2009-07-09 21:02:30 EDT --- This bug should be fixable at the xkb level IMHO without using immodule hacks. Moving to xkeyboard-config based on comment 18. (Please a separate bug for any quoting issues.) --- Additional comment from petersen(a)redhat.com on 2009-07-09 21:04:15 EDT --- (In reply to comment #25) > How about put im-cedilla.so to the separate package like gtk-immodules-cedilla > with the attached imsettings configuration file? you could update comps to > require that package for Brazilian Portuguese Language Support then. although > you need to choose that with im-chooser manually and need a bit updates on > imsettings to support immodule only configuration. Good point - we can certainly do that too - in fact doesn't require subpackaging per se. But I think the first attempt should be to fix this correctly with xkb support. --- Additional comment from petersen(a)redhat.com on 2009-07-10 02:37:01 EDT --- (In reply to comment #25) > Created an attachment (id=351200) --> (https://bugzilla.redhat.com/attachment.cgi?id=351200) [details] > im-cedilla.conf I opened bug 510666 to rfe adding xinput .conf to gtk2-immodules. --- Additional comment from rafael.espindola(a)gmail.com on 2009-07-13 17:32:04 EDT --- Just tried every combination of keyboards in By language -> Portuguese By country -> Brazil By country -> United States None has the desired effect of ' + c producing a ç. No having such a layout (I don't care about the name) is a major usability problem. Also, the layout should work in any application, using a gtk specific fix is not the way to go... --- Additional comment from petersen(a)redhat.com on 2009-09-01 20:23:20 EDT --- Hmm, what do other (commercial) OS's do for this? --- Additional comment from ehabkost(a)redhat.com on 2009-09-02 10:45:52 EDT --- On every pt_BR version of Windows I remember, the "US International" keyboard layout was the US keyboard layout where '+c produced ç. That's why the current behaviour is confusing for brazilian users coming from Windows. It is confusing even for former Linux users because on older Linux distributions, the US International keyboard layout on Xorg used to produce ç instead of ć. I have just checked this on a pt_BR Windows XP machine, and I get the expected behaviour if I select: language=EN, layout="US international" on the keyboard-layout applet. I don't know what would be the best solution for this, however. --- Additional comment from brunojcm(a)gmail.com on 2009-09-02 22:42:56 EDT --- Rafael and Eduardo just confirmed what people said all the time along this thread. All OS'es in all versions i know produced ç with ' + c until Fedora 11. I don't know how people who uses the ć configured their keyboard up to now, but they should have a way. Brazilian people with US keyboard layout don't have a way anymore. Fedora 11 changes the default behaviour without provide an alternative. As said Rafael, it's a major usability problem. Even the workaround proposed by me on Comment #20 works anymore, problably because some update I can't identify. I just don't understand why this behaviour changed occurred.. but I hope it's really necessary and the change worth enough. If someone have another workaround, i would really appreciate to know. Thanks --- Additional comment from petersen(a)redhat.com on 2009-09-03 06:33:06 EDT --- (In reply to comment #32) > Rafael and Eduardo just confirmed what people said all the time along this > thread. All OS'es in all versions i know produced ç with ' + c until Fedora 11. So I think we need a xkb layout with dead_acute + c -> ç. > I don't know how people who uses the ć configured their keyboard up to now, but > they should have a way. Brazilian people with US keyboard layout don't have a > way anymore. Fedora 11 changes the default behaviour without provide an > alternative. As said Rafael, it's a major usability problem. Dumb question probably: using the Brazil layout which has a Ç key would not be good enough? > I just don't understand why this behaviour changed occurred.. but I hope it's > really necessary and the change worth enough. Well it changed because we thought that the old gtk2 immodules are mostly hacks and should not be installed by default in Fedora. --- Additional comment from ehabkost(a)redhat.com on 2009-09-03 08:19:45 EDT --- (In reply to comment #33) > > Dumb question probably: using the Brazil layout which has a Ç key > would not be good enough? Not if your machine's keyboard has US layout and doesn't have a ç key. :) BR ABNT2 keyboards are also common in Brazil, but they have a completely different physical key layout (among other differences, you have an actual ç key on the keyboard). The problem here is for users who have US keyboards. --- Additional comment from petersen(a)redhat.com on 2009-09-17 03:11:09 EDT --- I see "us(intl)" has Alt_R + comma mapping to ccedilla. Does that help at all? What layout do people want to base on? --- Additional comment from rafael.espindola(a)gmail.com on 2009-09-17 09:06:41 EDT --- (In reply to comment #35) > I see "us(intl)" has Alt_R + comma mapping to ccedilla. > Does that help at all? Helps, but having the same behavior as previous versions (and windows) is better. > What layout do people want to base on? I think a us-intl with the '+c patched to produce ç would be perfect. --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-09-17 10:39:52 EDT --- Problem fixed. https://bugzilla.redhat.com/show_bug.cgi?id=510666 --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-09-17 18:16:16 EDT --- I think that's not a real fix, just a hack. It'll lead to GTK+ applications doing something different than other apps (e.g. Qt apps). --- Additional comment from petersen(a)redhat.com on 2009-09-17 20:38:22 EDT --- (In reply to comment #36) > I think a us-intl with the '+c patched to produce ç would be perfect. I think the only way to do that is to have "'" mapped to dead_cedilla which is not what you want I suppose. Peter, any comment? Seems to me that using dead_acute for this was a Bad Idea and people should rather get used to Alt_R Comma. How about Alt_R c -> ç that seems common? --- Additional comment from rafael.espindola(a)gmail.com on 2009-09-17 21:32:04 EDT --- I keep my opinion that fixing this is GTK is wrong. It has to work on Qt and on plain X. Alt_R c -> ç is a bit better (OS X is similar), but with windows being such a big part of the market I think the best it to just follow windows and keep the old behavior: ' + c -> ç. --- Additional comment from petersen(a)redhat.com on 2009-09-17 21:58:42 EDT --- Yes but how? The only other idea I can offer is an m17n-contrib input-method: Currently in fedora m17n-db-latin we have latn-post and latn-pre which provide c, -> ç and ,c -> ç respectively (plus lots of other accent bindings for qwerty), but it is trivial to make map for 'c -> ç, etc. --- Additional comment from rafael.espindola(a)gmail.com on 2009-09-17 22:09:39 EDT --- There must be a way, that was the behavior in older versions of fedora :-) Copying an old version of us-intl and renaming it to us-pt or us-pt_br should work, no? --- Additional comment from petersen(a)redhat.com on 2009-09-17 22:47:06 EDT --- (In reply to comment #42) > Copying an old version of us-intl and renaming it to us-pt or us-pt_br should > work, no? If you can attach it we can review. Which version of Fedora? Was X using the kernel us-acentos map then? As I see it the current choices are: A) use dead_cedilla (only needed for ccedilla) B) define ccedilla on a key (us(intl) provides it on Alt_R comma) C) use an input method to implement it. I think B or C are preferable. --- Additional comment from rafael.espindola(a)gmail.com on 2009-09-17 23:17:21 EDT --- comment #6 says Fedora 1 to 9. C is not a fix IMHO B using Alt_R + c is an improvement, but we would still have a regression A I think this would fix the problem. In fact, I think that is how us-intl used to work I just moved and don't have a Fedora machine with me right now. Should be able to test in one month. --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-09-18 00:17:16 EDT --- In Kde and in text mode the ' + c = ç is working fine, without extra configurations. I had problems only using gnome/gtk. --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-09-18 02:49:11 EDT --- "Solution" A would not really fix your problem, you could no longer enter things like á, é, í, ó, ú (and ý if you need that one) nor the apostrophe itself if ' was mapped to dead_cedilla. If I set the layout to us_intl in KDE (F10, KDE 4.3.1, de_AT.UTF-8 locale), I get ' + c = ć, not ç (and to be honest that's what I'd expect, especially from an *international* layout: if dead_acute + c is ç, how are people who want to type ć (needed at least for Polish and Croatian, and Serbian if written in Latin letters) supposed to get it?). But I think this may well be locale-dependant: the Compose tables are in /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer uses the locale-specific table? --- Additional comment from petersen(a)redhat.com on 2009-09-18 03:33:48 EDT --- I dunno I just tried in rawhide kde and get ' + c = ć. (In reply to comment #45) > In Kde and in text mode the ' + c = ç is working fine, without extra > configurations. Console is using us-acentos presumably? Please explain how to reproduce in KDE. --- Additional comment from rafael.espindola(a)gmail.com on 2009-09-18 09:44:28 EDT --- (In reply to comment #46) > "Solution" A would not really fix your problem, you could no longer enter > things like á, é, í, ó, ú (and ý if you need that one) nor the apostrophe > itself if ' was mapped to dead_cedilla. how about dead_acute + c = ç? I remember that '+' used to be ' > If I set the layout to us_intl in KDE (F10, KDE 4.3.1, de_AT.UTF-8 locale), I > get ' + c = ć, not ç (and to be honest that's what I'd expect, especially from > an *international* layout: if dead_acute + c is ç, how are people who want to > type ć (needed at least for Polish and Croatian, and Serbian if written in > Latin letters) supposed to get it?). Sure. Lets keep the us_intl what it is. It was enough pain to change it once. Just add a us_pt or something. > But I think this may well be locale-dependant: the Compose tables are in > /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps > dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer > uses the locale-specific table? I think '+c was producing ć everywhere (xterm, mozilla, konsole, etc), but I might be wrong. Can anyone with a current Federa install check that? --- Additional comment from petersen(a)redhat.com on 2009-09-23 05:08:00 EDT --- (I think with Compose (Multi_key) you could have "Compose comma c" -> ç) (In reply to comment #46) > But I think this may well be locale-dependant: the Compose tables are in > /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps > dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer > uses the locale-specific table? Oh yes - new to me... > So maybe what's going on is that GTK+ no longer > uses the locale-specific table? You're right - the locale compose seems to work for X11 and KDE apps. So seems indeed GTK is inconsistent here. --- Additional comment from petersen(a)redhat.com on 2009-09-23 05:17:45 EDT --- An extra wrinkle is that IM (at least ibus) seems to break the locale compose in KDE, but I assume you don't need input methods for now. --- Additional comment from mclasen(a)redhat.com on 2009-09-24 10:40:20 EDT --- GTK itself has never used the X compose tables, we have our own builtin table. And that table does in fact contain sequences for ç. E.g. try Compose_key , c Compose_key c , If you want to use the X compose tables in GTK+, you have to use xim. --- Additional comment from ehabkost(a)redhat.com on 2009-09-24 11:51:21 EDT --- (In reply to comment #51) > GTK itself has never used the X compose tables, we have our own builtin table. > And that table does in fact contain sequences for ç. E.g. try > Compose_key , c > Compose_key c , > > If you want to use the X compose tables in GTK+, you have to use xim. Sorry for the ignorance, but what does that mean for users that don't know what Input Methods are, have a US keyboard, install Fedora in pt_BR, and expect [']+[c] to produce [ç]? --- Additional comment from petersen(a)redhat.com on 2009-09-28 04:23:01 EDT --- I haven't succeeded yet in getting X compose working with im-xim.so - so would appreciate receiving clues/steps to do that. :) Is "GTK_IM_MODULE=xim" sufficient? (In reply to comment #52) > > If you want to use the X compose tables in GTK+, you have to use xim. > > Sorry for the ignorance, but what does that mean for users that don't know what > Input Methods are, have a US keyboard, install Fedora in pt_BR, and expect > [']+[c] to produce [ç]? IIUC it means that if one enables XIM on the desktop then your [']+[c] should work for pt_BR in gtk apps. However as I say above I haven't succeeded yet with doing that. --- Additional comment from petersen(a)redhat.com on 2009-09-28 05:15:14 EDT --- Nm, Tagoh-san pointed me in the right direction. - Need to make sure gtk2-immodule-xim is installed. ;) - Login from gdm with lang=pt_BR.UTF-8 and kbd=us(intl). - Run $ GTK_IM_MODULE=xim gedit. - Enter [']+[c] to produce [ç]. - Game over. :) But we need some imsettings to allow turning on XIM in this case. --- Additional comment from ehabkost(a)redhat.com on 2009-09-28 07:16:44 EDT --- Once this is fixed, will it be enabled by default on pt_BR + US-intl-keyboard installs? --- Additional comment from mclasen(a)redhat.com on 2009-09-28 10:08:35 EDT --- Jens, imsettings installs a file called /etc/X11/xinit/xinput.d/xim.conf. Is that not enough to make xim available via imsettings ? --- Additional comment from tagoh(a)redhat.com on 2009-09-28 21:46:32 EDT --- (In reply to comment #56) > Jens, imsettings installs a file called /etc/X11/xinit/xinput.d/xim.conf. Is > that not enough to make xim available via imsettings ? Since the most XIM servers requires the certain locale to work, it just provides the proper XIM servers for current locale to the users if available. xim.conf itself isn't useful if no xinput files are installed. You may need something like /etc/X11/xinit/xinput.d/xcompose with: XIM=none XIM_PROGRAM=/bin/true XIM_ARGS= SHORT_DESC="X locale compose" GTK_IM_MODULE=xim QT_IM_MODULE=xim and in %post %{_sbindir}/update-alternatives --install %{_sysconfdir}/X11/xinit/xinput.d/pt_BR xinput-pt_BR %{_sysconfdir}/X11/xinit/xinput.d/xcompose 50 %postun %{_sbindir}/update-alternatives --remove xinput-pt_BR %{_sysconfdir}/X11/xinit/xinput.d/xcompose I'm not sure if there are any requirements that people wants to use X compose regardless of current locale anyway. if there are, it may be good to not depend on xim.conf but put it as a standalone xinput file like scim and ibus does. FWIW there are a bug in imsettings if the system locale is different to what one gives to imsettings-* command and im-chooser say. so if you are going to test it with LANG=pt_BR.UTF-8 im-chooser or so, you may see an error message then. FYI I'll file a bug for that. --- Additional comment from petersen(a)redhat.com on 2009-09-28 23:22:54 EDT --- (In reply to comment #57) > and in %post > %{_sbindir}/update-alternatives --install > %{_sysconfdir}/X11/xinit/xinput.d/pt_BR xinput-pt_BR > %{_sysconfdir}/X11/xinit/xinput.d/xcompose 50 > > %postun > %{_sbindir}/update-alternatives --remove xinput-pt_BR > %{_sysconfdir}/X11/xinit/xinput.d/xcompose > > I'm not sure if there are any requirements that people wants to use X compose > regardless of current locale anyway. if there are, it may be good to not depend > on xim.conf but put it as a standalone xinput file like scim and ibus does. I think we should support X compose for any locale in principle so I suggest not to make it locale specific and call the xinput.d file say "xcompose.conf". (Is the name "X compose" broad enough to cover it?) Also I am not sure it needs to set QT_IM_MODULE though it probably doesn't hurt, or does Qt work because XIM is the default immodule anyway? --- Additional comment from tagoh(a)redhat.com on 2009-09-29 01:37:32 EDT --- (In reply to comment #58) > Also I am not sure it needs to set QT_IM_MODULE though it probably > doesn't hurt, or does Qt work because XIM is the default immodule > anyway? That may depends on how people set up on qtconfig. so it would be better adding that line too unless we don't mind either. --- Additional comment from tagoh(a)redhat.com on 2009-10-01 09:00:38 EDT --- (In reply to comment #58) > I think we should support X compose for any locale in principle > so I suggest not to make it locale specific and call the xinput.d > file say "xcompose.conf". (Is the name "X compose" broad enough > to cover it?) Or we could update none.conf to use im-xim.so but with XMODIFIERS=@im=none instead of gtk-im-context-simple. it doesn't requires the extra configurations. and it will keeps consistency among all of applications on X. --- Additional comment from petersen(a)redhat.com on 2009-10-01 23:27:10 EDT --- Sounds good to me - good idea :) --- Additional comment from tagoh(a)redhat.com on 2009-10-02 02:56:07 EDT --- I was trying to remember why I didn't make such change before. The impact on this change would be one has to restart their desktop after turning off/on IM every time since we stop imsettings-applet running by default and it depends on the change of XMODIFIERS anyway. Another concern is, some applications might becomes unstable when switching IM - one might freezes, one might crash etc - particularly when XMODIFIERS isn't @im=none. I've just brought up an idea. but not sure if it's really good. --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-10-28 15:08:17 EDT --- I'm trying Fedora 12 Beta and the problem is the same with this new version. When I choose Brazilian Portuguese and keyboard US International: ' + c = ć not ç It's a BIG usability problem for Brazilians because great part of our laptops are imported and the default keyboard is US International. --- Additional comment from rosset.filipe(a)gmail.com on 2009-10-29 09:32:57 EDT --- On Fedora 12 Beta ' + c = ç works with this steps... yum install gtk2-immodules System->Preferences->Input Methods-> Enable im-cedilla Logoff GDM Login PT_BR us_international (with dead keys) Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0, gnome-terminal 2.28.1 --- Additional comment from rodrigopadula(a)projetofedora.org on 2009-10-29 09:58:20 EDT --- Yes, it works since fedora 11, but, the Ç on US International keyboards must work automatically when I choose the BR Portuguese language + US International Keyboard. This is a big usability problem, mainly for new users. --- Additional comment from rafael.espindola(a)gmail.com on 2009-10-29 11:12:46 EDT --- (In reply to comment #64) > On Fedora 12 Beta ' + c = ç works with this steps... > > yum install gtk2-immodules > System->Preferences->Input Methods-> Enable im-cedilla > Logoff > > GDM Login > PT_BR > us_international (with dead keys) > > Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0, > gnome-terminal 2.28.1 This will not work on xterm or kterm or emacs, right? --- Additional comment from rosset.filipe(a)gmail.com on 2009-10-29 11:21:51 EDT --- (In reply to comment #66) > (In reply to comment #64) > > On Fedora 12 Beta ' + c = ç works with this steps... > > > > yum install gtk2-immodules > > System->Preferences->Input Methods-> Enable im-cedilla > > Logoff > > > > GDM Login > > PT_BR > > us_international (with dead keys) > > > > Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0, > > gnome-terminal 2.28.1 > > This will not work on xterm or kterm or emacs, right? Im test now on: xterm x86_64 248-2.fc12 rawhide 347 k and works fine. --- Additional comment from awilliam(a)redhat.com on 2009-10-29 13:36:41 EDT --- Bruno Medeiros requested on fedora-test-list that this be nominated as an F12 Blocker, we will discuss at tomorrow's meeting, 15:00 UTC in #fedora-bugzappers . Please come along to discuss this issue if you can. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers --- Additional comment from petersen(a)redhat.com on 2009-10-30 05:13:02 EDT --- > and works fine. Because im-cedilla.conf configures XIM also, so X compose takes care of the X apps. But currently we can't see any easy way for imseetings to make im-cedilla the default immodule for pt_BR. --- Additional comment from tagoh(a)redhat.com on 2009-10-30 05:34:28 EDT --- (In reply to comment #69) > > and works fine. > > Because im-cedilla.conf configures XIM also, > so X compose takes care of the X apps. > > But currently we can't see any easy way for imseetings > to make im-cedilla the default immodule for pt_BR. Even though it's XMODIFIERS=@im=none. in that sense, we could have the condition state in none.conf as well to enable im-cedilla for pt_BR and gtk-im-context-simple for others. what this way is better would be, it wouldn't need extra work to make it default for pt_BR users. it should works even after upgrading. --- Additional comment from myllynen(a)redhat.com on 2009-10-30 09:03:22 EDT --- I have read all the comments above and done quite some testing on Fedora 12 Beta. Below I summarize earlier findings, provide some additional information, and present one possible solution. Please feel free to complement my remarks if appropriate. Dysfunctional ' + c for Brazilian Portuguese is just one symptom of a much wider issue we have here. What is actually happening when a new user logs in is that GTK's builtin compose rule table is used regardless of user's locale settings. Apparently with earlier Fedora releases one's locale settings (LC_CTYPE or LANG) caused X compose rules to be taken into use but currently there seems to be no way to do that with GTK applications. Problems arise especially when these GTK builtin rules conflict with national/locale specific rules like in pt_BR or fi_FI. Using some character specific trick like im-cedilla is really not a feasible solution to the issue which literally covers thousands of compose rules. With non-GTK applications like xterm one can easily see how locale settings affect the compose rules in use: # yum install xterm xorg-X11-fonts-misc $ LC_CTYPE=en_US.UTF-8 xterm & $ LC_CTYPE=fi_FI.UTF-8 xterm & $ LC_CTYPE=pt_BR.UTF-8 xterm & Simple test cases for these three example locales are: dead_acute + c produces ć if using X's en_US.UTF-8/Compose (or GTK builtins) dead_acute + c produces ç if using X's pt_BR.UTF-8/Compose dead_acute + space produces ' if using en_US.UTF-8/Compose (or GTK builtins) dead_acute + space produces ´ if using fi_FI.UTF-8/Compose As mentioned several times in the earlier comments the default for Brazilian Portuguese is not acceptable. Situation with Finnish is also very challenging since there is an official national standard which defines both keyboard layout and compose rules. As explained above now it seems impossible to comply with this standard with Fedora 12 although X already implements everything what would be needed (i.e., both keyboard layout and X compose rules). One possible solution to solve all the issues discussed here could be: 1. Use any Input Method system like IBus or SCIM if configured by the user 2. If no Input Method system configured use X/locale settings (default) 3. If both previous methods fail or are unavailable use GTK builtin rules This scheme would mean that en_US users would not notice any difference compared to the current situation, users of locales like pt_BR and fi_FI would notice their keyboards working by default, and others who need an advanced input system (like ja_JP users) could enable it at will as always. It would also provide a consistent user experience when switching between GTK applications (e.g., gnome-terminal) and non-GTK applications (e.g., xterm). Also, if an individual compose rule or keymapping is found to be problematic within a locale, then it would be only a locale specific issue, no system level changes would be needed at all. And should there be changes needed for an Input Method system only those users who have enabled that particular Input Method system would be affected. I will take part of the IRC session later today where we can discuss this issue in more detail. Thanks. --- Additional comment from petersen(a)redhat.com on 2009-10-30 10:01:24 EDT --- Thank Marko for the good detailed summary and the Finnish perspective also. (I am glad this also resurfaced in the i18n Test Day this week.) (In reply to comment #71) > Problems arise especially when these GTK builtin rules conflict with > national/locale specific rules like in pt_BR or fi_FI. Using some character > specific trick like im-cedilla is really not a feasible solution to the issue > which literally covers thousands of compose rules. Right - as also noted here earlier. > 1. Use any Input Method system like IBus or SCIM if configured by the user > 2. If no Input Method system configured use X/locale settings (default) > 3. If both previous methods fail or are unavailable use GTK builtin rules My suggests are: 1) avoid im-cedilla.so 2) install gtk2-immodules-xim by default (or better move im-xim.so back into gtk2?) 3) try to make im-xim.so the default gtk immodule (which corresponds to Marco's (2) instead of gtk-im-context-simple, as Akira also suggested. 4) everyone (gtk, qt, X) happy In fact I have pushed for this in the past (see bug 452938) to bring parity with qt which has long defaulted to XIM (probably because of its European heritage?:) I think fedora-i18n can help to work on this in the coming days, though it is getting rather late for f12-final... It might be more realistic to target day-zero updates to not risk destabilizing and further delaying the release at this stage: I think that was our original intention. --- Additional comment from awilliam(a)redhat.com on 2009-10-30 14:17:21 EDT --- Discussed at the blocker bug meeting today. The thing that worries me is that if we fix this as a 0-day update it won't be fixed during installation. However, I've been told that the need to type a ç during installation is likely to be quite small for most Brazilian users, so on that basis we agreed that dropping it to F12Target and aiming to fix it with a 0-day update is OK. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers --- Additional comment from mclasen(a)redhat.com on 2009-10-30 14:22:38 EDT --- I don't want to bring xim back into the main gtk package. Imo, this is a step back. We need to have a single input method framework that actually works for everybody, not a patchwork where you have to pick whatever works best for your language. --- Additional comment from kevin(a)tigcc.ticalc.org on 2009-10-30 14:26:32 EDT --- It's also not really true that Qt uses XIM by default. We don't even ship XIM on the KDE spin. It might pick it up by default if you install it (and no other input method package), but normally there's no XIM installed at all. --- Additional comment from petersen(a)redhat.com on 2009-10-31 06:17:03 EDT --- (In reply to comment #74) > I don't want to bring xim back into the main gtk package. > Imo, this is a step back. What is the problem with replacing gtk-im-context-simple with im-xim.so as the default IM context? I see it as a step forward not a step back. :) > We need to have a single input method framework that actually works for > everybody, not a patchwork where you have to pick whatever works best for your > language. Well I would like that ibus can also handle X compose better: hopefully for f13 but rather unlikely for f12 release... we need a fix now this has been broken since f11. :-( It is not a patchwork but consistent with qt's behaviour. (In reply to comment #75) > It's also not really true that Qt uses XIM by default. Erm, we are talking about qt immodules here - sorry for being unclear perhaps: try running "QT_IM_MODULE= qtconfig-qt4" -> Interface and looking at "Default Input Method". Anyway Qt already works the discussion here is about X and gtk apps. --- Additional comment from petersen(a)redhat.com on 2009-10-31 07:29:05 EDT --- Created an attachment (id=366913) --> (https://bugzilla.redhat.com/attachment.cgi?id=366913) imsettings-none.conf-xim.patch My recommendation to fix this serious problem for International users: Add to the comps-f12 input-methods group: <packagereq type="conditional" requires="gtk2">gtk2-immodule-xim</packagereq> and apply the above patch to imsettings none.conf to make imsettings default GTK_IMMODULE to xim when available. My main remaining concern though is multilib issues: eg when users have gtk2.x86_64 and gtk2.i686 installed but only gtk2-immodule-xim for one arch. For this reason I really wish Matthias will give my idea to move im-xim.so back into the main gtk2 package further consideration. --- Additional comment from petersen(a)redhat.com on 2009-10-31 07:34:17 EDT --- If people could test the above patch it would be appreciated (be sure to turn-off IM in im-chooser to make sure you are using none.conf, and restart your desktop session). It seems to works well enough for me so far on i686 anyway. --- Additional comment from mclasen(a)redhat.com on 2009-10-31 14:39:48 EDT --- > Dysfunctional ' + c for Brazilian Portuguese is just one symptom of a much > wider issue we have here. What is actually happening when a new user logs > in is that GTK's builtin compose rule table is used regardless of user's locale > settings. Apparently with earlier Fedora releases one's locale settings > (LC_CTYPE or LANG) caused X compose rules to be taken into use but currently > there seems to be no way to do that with GTK applications. Depends on what you mean with 'locale settings' here. If you don't use an input method framework like scim or ibus (or iiimf or xim or whatever else is in vogue) you get whatever compose sequences that method provides, which may depend on your locale or not. If you don't use an input method framework, GTK+ uses its builtin simple input method, which has a large, but fixed table of compose sequences. This has always been the case. Nothing has changed in GTK+ here. --- Additional comment from petersen(a)redhat.com on 2009-11-01 08:19:37 EST --- (In reply to comment #79) > This has always been the case. Nothing has changed in GTK+ here. Right. What changed in F11 is we stopped installing im-cedilla by default and hence this bug report. (I was probably partly to blame for that decision: not that it was wrong in itself, just that we didn't provide a saner substitute, since I don't think we were aware then of its wide use for pt_BR.) It seems clear now that im-cedilla was merely a hack to workaround the lack of X compose support in gtk-im-context-simple, which is provided through im-xim.so. Using im-xim.so should give us consistent keyboard input for all locales across X, GTK, and Qt applications which is a big usability plus for users dependent on X compose for writing their language. --- Additional comment from mclasen(a)redhat.com on 2009-11-01 09:25:21 EST --- > It seems clear now that im-cedilla was merely a hack > to workaround the lack of X compose support in gtk-im-context-simple, > which is provided through im-xim.so. Using im-xim.so > should give us consistent keyboard input for all locales > across X, GTK, and Qt applications which is a big usability plus > for users dependent on X compose for writing their language. I can only repeat my position on this: We need a single input method framework and we need to tighly integrate it with keyboard layout configuration and the rest of the desktop. Tagging input method support onto desktops 'from the side' and trying to make it both 'desktop-neutral' and 'im-framework-neutral' is always going to provide an insufficient user experience. --- Additional comment from petersen(a)redhat.com on 2009-11-01 20:30:43 EST --- I agree wholeheartedly - I see that as a long-term goal for tight IM integration on the desktop. I feel we are gradually moving in the right direction, and I would like to collaborate on this. --- Additional comment from petersen(a)redhat.com on 2009-11-02 04:59:00 EST --- I built http://koji.fedoraproject.org/koji/buildinfo?buildID=139343 to help with this issue: please test it with gtk2-immodule-xim and report any problems or successes here. --- Additional comment from myllynen(a)redhat.com on 2009-11-03 11:20:37 EST --- Thanks Jens, I've now tested your new packages on two test systems and the issue seems to be solved! I'll document some additional details below if someone happens to struggle with this one in the future. After installing gtk2-immodule-xim and disabling any Input Method (if in use) one just needs to logout and login with an appropriate language and X compose sequences should thenbe in use also in GTK applications. User experience between GTK and non-GTK applications is now consistent. In practice one can either choose an appropriate (native) language for the whole session at GDM login prompt (like Brazilian Portuguese or Finnish) which will set up LANG environment variable or adjust LC_CTYPE in a shell init script allowing use of a language like US English for the session but still having native compose sequences. The only limitation seems to be that one can't set LC_CTYPE per window basis but needs it for the whole session but I don't think that's a problem, really. Should there be any issues still checking 'locale´ output might give some clues as well as contents of ~/.dmrc. --- Additional comment from updates(a)fedoraproject.org on 2009-11-07 23:54:18 EST --- imsettings-0.107.4-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/imsettings-0.107.4-3.fc12 --- Additional comment from updates(a)fedoraproject.org on 2009-11-10 12:52:42 EST --- imsettings-0.107.4-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update imsettings'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11244 --- Additional comment from petersen(a)redhat.com on 2009-11-11 19:32:49 EST --- Please test and feel free to bump karma in Bodhi to get this pushed to F12 updates. --- Additional comment from updates(a)fedoraproject.org on 2009-11-27 17:02:57 EST --- imsettings-0.107.4-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 19

[Fedora-i18n-bugs] [Bug 586297] New: Improve wqy-microhei-fonts fontconfig conf file.
by Red Hat Bugzilla 23 Jun '10

23 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Improve wqy-microhei-fonts fontconfig conf file. https://bugzilla.redhat.com/show_bug.cgi?id=586297 Summary: Improve wqy-microhei-fonts fontconfig conf file. Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: wqy-microhei-fonts AssignedTo: pwu(a)redhat.com ReportedBy: tagoh(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, phuang(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com Classification: Fedora Target Release: --- Clone Of: 568613 +++ This bug was initially created as a clone of Bug #568613 +++ Currently we are considering split the "Chinese support" package group into "Simplified Chinese Support" and "Traditional Chinese Support" package groups. To provide different rpm package sets for TC and SC users. This is part of the changes needed be done in wqy fonts. So we want to change the following section in wqy-microhei-fonts-fontconfig.conf and wqy-zenhei-fontconfig.conf. From: <match> <test name="lang"> <string>zh</string> </test> ... </match> To: <match> <test name="lang"> <string>zh-cn</string> </test> ... </match> What do you think about these changes? --- Additional comment from pwu(a)redhat.com on 2010-02-26 01:58:59 EST --- Sorry, just find Qianqian Fang is not in the CC list or owner. So add him to CC list, and copy the above message here. Hi Qianqian Fang, what is your opinion about this change? (In reply to comment #0) > Currently we are considering split the "Chinese support" package group into > "Simplified Chinese Support" and "Traditional Chinese Support" package groups. > To provide different rpm package sets for TC and SC users. > > This is part of the changes needed be done in wqy fonts. > > So we want to change the following section in > wqy-microhei-fonts-fontconfig.conf and wqy-zenhei-fontconfig.conf. > From: > <match> > <test name="lang"> > <string>zh</string> > </test> > ... > </match> > To: > <match> > <test name="lang"> > <string>zh-cn</string> > </test> > ... > </match> > > What do you think about these changes? --- Additional comment from fangqq(a)gmail.com on 2010-02-26 10:01:54 EST --- this is not necessary. AFAIK, there are no traditional-styled open-source vector fonts (with good coverage and quality as zenhei/microhei) exist. UMing/UKai/ZenHei/MicroHei are mostly following Unicode standard shapes (which is based on simplified Chinese style). If you limit these fonts to simplified Chinese users only, the traditional Chinese users will likely end up with Japanese fonts, which are even worse in both coverage and glyph consistency. I heard mostly positive feedbacks from traditional Chinese users for these fonts, you may browse the following google link to find out: http://www.google.com/#hl=en&q=%E6%96%87%E6%B3%89%E9%A9%9B+%E5%AD%97%E5%9E%… In the long run, I would prefer to eliminate all the font preference sections in these font conf files, and rely on the updated 65-nonlatin and language-specific conf files to set orders. see http://bugs.freedesktop.org/show_bug.cgi?id=20911 https://bugzilla.redhat.com/show_bug.cgi?id=499902 --- Additional comment from petersen(a)redhat.com on 2010-03-04 01:00:46 EST --- I think we need it for fedora and we want to mark uming and ukai as non zh_CN in their fontconfig. --- Additional comment from fangqq(a)gmail.com on 2010-03-04 10:35:35 EST --- (In reply to comment #3) > I think we need it for fedora and we want to mark uming and ukai > as non zh_CN in their fontconfig. why? there are not many free Chinese fonts (simplified or traditional) available, Uming/UKai are the only good quality fonts for Song and Kai styles, respectively. Standard Chinese text layout generally requires 4 styles: Song, Hei, Kai, Fang-Song. If you mark it for only one language variant, that means the other language variants will lose half usable Chinese font styles! I am pretty sure most Chinese users will against this. --- Additional comment from pwu(a)redhat.com on 2010-03-04 21:19:09 EST --- Actually what we want to change is as following: 1. Make wqy-zenhei as default for Simplified Chinese users, Make UMing as default for Traditional Chinese users. When user choose "Sans" / "Serif" / "MonoSpace": 1. In zh_CN locale, it will use "Zen Hei" as default, 2. In zh_TW locale, it will use "UMing" as default. If you installed both zenhei and Uming/Ukai, I think it will show in font list when querying with fontconfig. In brief, we just want to change the default fonts for SC and TC users. The font styles is still available when the fonts is installed. Currently I am trying to change font conf to achieving this, but meet some problems. Maybe you could help me on this. --- Additional comment from fangqq(a)gmail.com on 2010-03-05 11:54:30 EST --- I responded by email last night, but it did not show up, so I paste my response again. > --- Comment #5 from Peng Wu<pwu(a)redhat.com> 2010-03-04 21:19:09 EST --- > Actually what we want to change is as following: > 1. Make wqy-zenhei as default for Simplified Chinese users, > Make UMing as default for Traditional Chinese users. > I am not sure which language did you use in the past, but I do see a couple of problems here: First of all, Zen Hei and UMing are fonts of different styles. one is Sans, one is Serif (let's ignore the embedded bitmaps for a second). They are more like Dejavu Sans vs. Dejavu Serif, than like Droid Sans Fallback vs. Droid Sans Japanese. They mean to represent different types of visual elements in the text layout (and used simultaneously), and not meant to represent the same information for different languages. Second, UMing/UKai are not "consistently" traditional Chinese styled. For most glyphs, they are rather mainland Chinese styled. It does contain traditional Chinese styled characters as merged from AR PL Mingti2L Big5, but they are not consistent, for example, all the components with "角" are SC-styled (唃嘝嘴嶰廨懈斛桷槲檞澥确繲薢角觙觚觛觜觞觟觠解觥觧觫觭觯觲觳觺觻邂鵤); many "骨" components are TC, but several are SC, such as "骶骺髅髋髌鹘"; all the "今" components are SC, such as in "今仱侺吟妗岑岒庈忴扲昑枔棽涔琌琴矜笒紟耹肣芩蚙衿軡鈐钤霒霠黔"; almost all chars with radical "黑" are SC, except "黓" is TC. I can not give all of the examples, there are so many inconsistencies. If you are interested, you can download a copy of Unicode code chart (second column) and compare with Uming glyphs: http://unicode.org/charts/PDF/U4E00.pdf > When user choose "Sans" / "Serif" / "MonoSpace": > 1. In zh_CN locale, it will use "Zen Hei" as default, > 2. In zh_TW locale, it will use "UMing" as default. > Personally, I like the way Ubuntu handles this: Zen Hei is the default CJK Sans font, and UMing is the default Serif font. On LiveCDs where space is limited, only one font is installed, before 9.10, it was UMing, after 9.10, it was ZenHei. > If you installed both zenhei and Uming/Ukai, I think it will show in font list > when querying with fontconfig. > > In brief, we just want to change the default fonts for SC and TC users. The > font styles is still available when the fonts is installed. > At this point, there is no TC-shaped fonts available. So, you can't really solve this by splitting zenhei/uming, as both of them are mostly SC-styled Unicode fonts. I do have the plan to create TC variant of ZenHei, and Arne also split the font names to UMing CN/UMing TW, but there are lot of things need to be done to make them TC consistent. > Currently I am trying to change font conf to achieving this, but meet some > problems. Maybe you could help me on this. > As I said, set zenhei/microhei for sans, set uming for serif, that's probably the best we can do. In addition, giving users an easy way to switch between bitmaps and anti-aliased glyphs is probabily a much useful feature than setting SC/TC with separate default fonts. --- Additional comment from tagoh(a)redhat.com on 2010-03-16 01:01:31 EDT --- (In reply to comment #6) > Personally, I like the way Ubuntu handles this: Zen Hei is > the default CJK Sans font, and UMing is the default Serif font. > On LiveCDs where space is limited, only one font is installed, > before 9.10, it was UMing, after 9.10, it was ZenHei. This is just out of curiosity, do they use Zen Hei as the default _CJK_ Sans font really? but not as the default Sans font for Chinese? --- Additional comment from fangqq(a)gmail.com on 2010-03-16 01:36:13 EDT --- (In reply to comment #7) > This is just out of curiosity, do they use Zen Hei as the default _CJK_ Sans > font really? but not as the default Sans font for Chinese? ok, it was not accurate, Zen Hei was just for Chinese. For non-CJK locales, however, fontconfig does pick up Zen Hei to display Han characters. Here is example package lists for live cds (9.04/9.10): http://cdimage.ubuntu.com/releases/jaunty/release/ubuntu-9.04-mid-lpia.mani… http://cdimage.ubuntu.com/xubuntu/releases/9.10/release/xubuntu-9.10-deskto… For 10.04, microhei replaced zenhei: http://cdimage.ubuntu.com/daily-live/current/lucid-desktop-i386.manifest --- Additional comment from pwu(a)redhat.com on 2010-03-29 03:38:20 EDT --- Hi, Here are a new proposal, and finally have a draft font confs for this. And the result is as following: 1. When use Simplified Chinese (SC for brief) locale to login Fedora gdm, all default desktop fonts will use WenQuanYi; 2. When use Traditional Chinese (TC for brief) locale to login Fedora gdm, all default desktop fonts will use UMing. For more information and how to test the new proposal, please visit the URL here (also with a README): http://pwu.fedorapeople.org/fonts-conf/ Thanks, please review it. --- Additional comment from petersen(a)redhat.com on 2010-04-07 07:34:07 EDT --- Following Tagoh's proposal in bug 578015: we probably have to drop binding="same". Does that help too? --- Additional comment from fangqq(a)gmail.com on 2010-04-07 13:58:33 EDT --- I am assigning Peng to look into the issue. I don't really have time to work on these packages any more. I am sure Peng will do a good job, with feed backs from Fedora Chinese List, to maintain the Chinese-related font packages. --- Additional comment from pwu(a)redhat.com on 2010-04-07 22:28:06 EDT --- (In reply to comment #10) > Following Tagoh's proposal in bug 578015: we probably have to drop > binding="same". > > Does that help too? I commented on https://bugzilla.redhat.com/show_bug.cgi?id=578051#c1( lang-specific overrides rule doesn't work as expected). >From the test result, It seems that removing the binding="same" helps split between English and Chinese fonts. But Chinese fonts seems still the same. --- Additional comment from pwu(a)redhat.com on 2010-04-07 22:33:18 EDT --- (In reply to comment #11) > I am assigning Peng to look into the issue. I don't really have time to work on > these packages any more. I am sure Peng will do a good job, with feed backs > from Fedora Chinese List, to maintain the Chinese-related font packages. Hi, thanks. I will handle this bug. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Fedora-i18n-bugs] [Bug 584614] New: typo in g_fname.t
by Red Hat Bugzilla 21 Jun '10

21 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: typo in g_fname.t https://bugzilla.redhat.com/show_bug.cgi?id=584614 Summary: typo in g_fname.t Product: Fedora Version: 12 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: anthy AssignedTo: tagoh(a)redhat.com ReportedBy: masanari_iida(a)hp.com QAContact: extras-qa(a)fedoraproject.org CC: tagoh(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Target Release: --- Description of problem: There is a typo in anthy-9100h/alt-cannadic/g_fname.t Version-Release number of selected component (if applicable): anthy-9100h-8.fc12 How reproducible: Always Typo anthy-9100h/alt-cannadic/g_fname.t Wrong: あべこうぼう #JN*10 #_2阿部_4公房 Correct: あべこうぼう #JN*10 #_2安部_4公房 Additional info: This typo can be found Fedora 11 to 13(beta). anthy-9100h/mkworddic/name.t also has the same typo. But according to mkworddic/dict.args.in, name.t is not used. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 13

← Newer
1
...
14
15
16
17
18
19
20
...
44
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs May 2010