April 2012 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 513901] New: ibus-table setup does not store config settings

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: ibus-table setup does not store config settings https://bugzilla.redhat.com/show_bug.cgi?id=513901 Summary: ibus-table setup does not store config settings Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: ibus-table AssignedTo: cchance(a)redhat.com ReportedBy: petersen(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: cchance(a)redhat.com, phuang(a)redhat.com, fedora-i18n-bugs(a)redhat.com Estimated Hours: 0.0 Classification: Fedora Target Release: --- Description of problem: ibus-table config is not using gconf to store configuration settings. Steps to Reproduce: 1. change ibus-table config 2. restart desktop 3. use ibus-table Actual results: configuration lost Expected results: configuration to persist -- 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.

11 years, 3 months

1
25
0 / 0

[Fedora-i18n-bugs] [Bug 795074] New: [abrt] imsettings-1.2.8-1.fc16: _dl_sort_fini: Process /usr/bin/imsettings-check was killed by signal 11 (SIGSEGV)

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] imsettings-1.2.8-1.fc16: _dl_sort_fini: Process /usr/bin/imsettings-check was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=795074 Summary: [abrt] imsettings-1.2.8-1.fc16: _dl_sort_fini: Process /usr/bin/imsettings-check was killed by signal 11 (SIGSEGV) Product: Fedora Version: 16 Platform: i686 OS/Version: Unspecified Status: NEW Status Whiteboard: abrt_hash:c4186403d3fe7a83ebee390a6e04805960a25530 Severity: unspecified Priority: unspecified Component: imsettings AssignedTo: tagoh(a)redhat.com ReportedBy: ttonybrowning(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: tagoh(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- libreport version: 2.0.8 abrt_version: 2.0.7 backtrace_rating: 4 cmdline: imsettings-check --check-dbus comment: installing updates then crashed. crash_function: _dl_sort_fini executable: /usr/bin/imsettings-check kernel: 3.1.0-7.fc16.i686 pid: 1421 pwd: /home/tonybrowning reason: Process /usr/bin/imsettings-check was killed by signal 11 (SIGSEGV) time: Sat 18 Feb 2012 11:38:55 PM EST uid: 1000 username: tonybrowning var_log_messages: Feb 18 23:38:56 toshiba abrt[1423]: Saved core dump of pid 1421 (/usr/bin/imsettings-check) to /var/spool/abrt/ccpp-2012-02-18-23:38:55-1421 (9113600 bytes) xsession_errors: /etc/X11/xinit/xinitrc.d/50-xinput.sh: line 24: 1421 Segmentation fault (core dumped) imsettings-check --check-dbus backtrace: Text file, 16906 bytes maps: Text file, 4795 bytes build_ids: :4ad17dce13b95c3f6543c3ab56624e321dc1fce8 :fb138a019cd93aa6212be49f31654f7bcb474640 :798697a352bae4178953ba502fb04f33dd0ed987 :1df53725e371c75ee897f32d82ec0497ecbb8599 :e86c829bf8553d6b593dbd8c4df0957268dc8328 :879571cf1e8dd31736d0f24b55e0daffc1591278 :d1bd2374eb12ee6116690a80ce23d695b3d585e8 :15bab279752ad8e30f901abae77bcb1ed1f38977 :59c22a603e066352375b9abf33e25e455885e29c :641296f1c3020865058939e8629a44acffcc3339 :92418f7b783e29ab8440148e3fb0cbcfb8bb354a :5d34a26f81175d62c3617701cb9f83f450700f43 :39115138ce2cd82c97324f17286b7b5941fbdef1 :f8e2e3adf420486889169759ccf806dc393ca12f :d7cd016536dcce05ea28a1219c92eb9507121fa3 :bdbcb7ad0ae16806e9002af3c6d1ec65353108a0 :12da4d1dc9764d3990ab6a2def5a88c4687d4550 :1f60ce3a43a5e6db2df2252da25ac0aa9f90b6b9 :85d6747093886eff44cf10e88d3eb9c88b6eb95d :36cc7c0490b1d29bbe496654fe01dea01f6c8615 :10cec21724c13b95ec03f00985b0405412817a49 dso_list: :/lib/libdl-2.14.90.so glibc-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617650 :/lib/libgthread-2.0.so.0.3000.1 glib2-2.30.1-1.fc16.i686 (Fedora Project) 1329122068 :/lib/libgcc_s-4.6.2-20111027.so.1 libgcc-4.6.2-1.fc16.i686 (Fedora Project) 1329122052 :/usr/lib/libXau.so.6.0.0 libXau-1.0.6-2.fc15.i686 (Fedora Project) 1317262709 :/lib/libgmodule-2.0.so.0.3000.1 glib2-2.30.1-1.fc16.i686 (Fedora Project) 1329122068 :/usr/lib/libX11.so.6.3.0 libX11-1.4.3-1.fc16.i686 (Fedora Project) 1317262709 :/lib/libresolv-2.14.90.so glibc-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617650 :/lib/libgobject-2.0.so.0.3000.1 glib2-2.30.1-1.fc16.i686 (Fedora Project) 1329122068 :/lib/librt-2.14.90.so glibc-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617650 :/lib/libpthread-2.14.90.so glibc-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617650 :/usr/lib/libimsettings.so.5.2.0 imsettings-libs-1.2.8-1.fc16.i686 (Fedora Project) 1329122100 :/usr/lib/libxcb.so.1.1.0 libxcb-1.7-3.fc16.i686 (Fedora Project) 1317262709 :/lib/ld-2.14.90.so glibc-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617650 :/usr/bin/imsettings-check imsettings-1.2.8-1.fc16.i686 (Fedora Project) 1329122164 :/lib/libselinux.so.1 libselinux-2.1.6-6.fc16.i686 (Fedora Project) 1329122062 :/usr/lib/libffi.so.5.0.10 libffi-3.0.10-1.fc16.i686 (Fedora Project) 1329122066 :/lib/libz.so.1.2.5 zlib-1.2.5-4.fc16.i686 (Fedora Project) 1317262706 :/lib/libglib-2.0.so.0.3000.1 glib2-2.30.1-1.fc16.i686 (Fedora Project) 1329122068 :/lib/libc-2.14.90.so glibc-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617650 :/usr/lib/locale/locale-archive glibc-common-2.14.90-24.fc16.4.i686 (Fedora Project) 1329617635 :/lib/libgio-2.0.so.0.3000.1 glib2-2.30.1-1.fc16.i686 (Fedora Project) 1329122068 environ: :XDG_VTNR=1 :XDG_SESSION_ID=2 :IMSETTINGS_INTEGRATE_DESKTOP=yes :TERM=dumb :SHELL=/bin/bash :XDG_SESSION_COOKIE=0ffc44e42efe049981d3787c0000000d-1329626335.48821-1906449258 :GNOME_KEYRING_CONTROL=/tmp/keyring-KvV412 :IMSETTINGS_MODULE=none :USER=tonybrowning :USERNAME=tonybrowning :DESKTOP_SESSION=gnome :PATH=/usr/local/bin:/usr/bin:/bin :QT_IM_MODULE=xim :PWD=/home/tonybrowning :XMODIFIERS=@im=none :LANG=en_US.UTF-8 :GNOME_KEYRING_PID=1306 :GDMSESSION=gnome :SHLVL=1 :XDG_SEAT=seat0 :HOME=/home/tonybrowning :LOGNAME=tonybrowning :DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-EyUaCDBYuV,guid=fee2b9404b92a495e8ba0c610000004f :WINDOWPATH=1 :DISPLAY=:0 :XDG_RUNTIME_DIR=/run/user/tonybrowning :XAUTHORITY=/var/run/gdm/auth-for-tonybrowning-6rJ28V/database :_=/usr/bin/imsettings-check event_log: :2012-02-19-00:38:56> Analyzing coredump 'coredump' :2012-02-19-00:39:10 Coredump references 21 debuginfo files, 2 of them are not installed :2012-02-19-00:39:13 Setting up yum repositories :2012-02-19-00:39:13 Looking for needed packages in repositories :2012-02-19-00:39:17 Packages to download: 1 :2012-02-19-00:40:07 Downloading 0.29Mb, installed size: 1.12Mb. Continue? YES :2012-02-19-00:40:28 Downloading (1 of 1) imsettings-debuginfo-1.2.8-1.fc16.i686.rpm: 44 :2012-02-19-00:40:33 Downloading (1 of 1) imsettings-debuginfo-1.2.8-1.fc16.i686.rpm: 100 :2012-02-19-00:40:35 Extracting cpio from /tmp/abrt-tmp-debuginfo-2012-02-19-00:39:01.1855/imsettings-debuginfo-1.2.8-1.fc16.i686.rpm :2012-02-19-00:40:40 Caching files from unpacked.cpio made from imsettings-debuginfo-1.2.8-1.fc16.i686.rpm :2012-02-19-00:40:41 Removing /tmp/abrt-tmp-debuginfo-2012-02-19-00:39:01.1855 :2012-02-19-00:40:42 All 21 debuginfo files are available :2012-02-19-00:40:44 Generating backtrace :2012-02-19-00:40:53 Backtrace is generated and saved, 16906 bytes :2012-02-19-00:41:21> Element 'xsession_errors' saved :2012-02-19-00:41:49> Smolt profile successfully saved smolt_data: : : :General :================================= :UUID: 219ed543-db70-45fe-898b-43908bcb897e :OS: Fedora release 16 (Verne) :Default run level: Unknown :Language: en_US.UTF-8 :Platform: i686 :BogoMIPS: 3457.48 :CPU Vendor: GenuineIntel :CPU Model: Genuine Intel(R) CPU T2250 @ 1.73GHz :CPU Stepping: 8 :CPU Family: 6 :CPU Model Num: 14 :Number of CPUs: 2 :CPU Speed: 1733 :System Memory: 993 :System Swap: 2015 :Vendor: TOSHIBA :System: Satellite A100 PSB10U-SA10ES1 :Form factor: Other :Kernel: 3.1.0-7.fc16.i686 :SELinux Enabled: 1 :SELinux Policy: targeted :SELinux Enforce: Enforcing :MythTV Remote: Unknown :MythTV Role: Unknown :MythTV Theme: Unknown :MythTV Plugin: :MythTV Tuner: -1 : : :Devices :================================= :(4172:32827:4473:65296) pci, tifm_7xx1, STORAGE, 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) :(32902:4242:4473:65296) pci, e100, ETHERNET, PRO/100 VE Network Connection :(32902:10144:4473:65296) pci, agpgart-intel, HOST/PCI, Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub :(4172:32826:4473:65296) pci, firewire_ohci, FIREWIRE, PCIxx12 OHCI Compliant IEEE 1394 Host Controller :(4172:32825:4473:65296) pci, yenta_cardbus, PCI/CARDBUS, PCIxx12 Cardbus Controller :(4172:32828:4473:65296) pci, sdhci-pci, BASE, PCIxx12 SDA Standard Compliant SD Host Controller :(32902:10169:4473:65296) pci, None, PCI/ISA, 82801GBM (ICH7-M) LPC Interface Bridge :(32902:10196:4473:65296) pci, pcieport, PCI/PCI, N10/ICH 7 Family PCI Express Port 3 :(32902:9288:4473:65296) pci, None, PCI/PCI, 82801 Mobile PCI Bridge :(32902:10185:4473:65296) pci, uhci_hcd, USB, N10/ICH 7 Family USB UHCI Controller #2 :(32902:10184:4473:65296) pci, uhci_hcd, USB, N10/ICH 7 Family USB UHCI Controller #1 :(32902:10187:4473:65296) pci, uhci_hcd, USB, N10/ICH 7 Family USB UHCI Controller #4 :(32902:10186:4473:65296) pci, uhci_hcd, USB, N10/ICH 7 Family USB UHCI Controller #3 :(32902:10188:4473:65296) pci, ehci_hcd, USB, N10/ICH 7 Family USB2 EHCI Controller :(32902:10146:4473:65296) pci, None, VIDEO, Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller :(32902:10150:4473:65296) pci, None, VIDEO, Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller :(32902:10192:4473:65296) pci, pcieport, PCI/PCI, N10/ICH 7 Family PCI Express Port 1 :(32902:10194:4473:65296) pci, pcieport, PCI/PCI, N10/ICH 7 Family PCI Express Port 2 :(32902:10200:4473:65296) pci, snd_hda_intel, MULTIMEDIA, Toshiba Satellite A100-796 audio (Realtek ALC861) :(32902:10202:4473:65296) pci, i801_smbus, SERIAL, N10/ICH 7 Family SMBus Controller :(32902:16930:32902:4160) pci, iwl3945, NETWORK, PRO/Wireless 3945ABG [Golan] Network Connection :(32902:10180:4473:65296) pci, ata_piix, STORAGE, 82801GBM/GHM (ICH7 Family) SATA IDE Controller : : :Filesystem Information :================================= :device mtpt type bsize frsize blocks bfree bavail file ffree favail :------------------------------------------------------------------- :/dev/mapper/vg_toshiba-lv_root / ext4 4096 4096 12901535 11552182 11421160 3276800 3146068 3146068 :/dev/sda1 /boot ext4 1024 1024 495844 438481 412881 128016 127792 127792 :/dev/mapper/vg_toshiba-lv_home /home ext4 4096 4096 10498372 10105200 9571901 2670592 2669784 2669784 : -- 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.

11 years, 3 months

1
4
0 / 0

[Fedora-i18n-bugs] [Bug 572611] New: ibus should ensure that ~/.config/ibus/bus exists

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: ibus should ensure that ~/.config/ibus/bus exists https://bugzilla.redhat.com/show_bug.cgi?id=572611 Summary: ibus should ensure that ~/.config/ibus/bus exists Product: Fedora Version: 12 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: ibus AssignedTo: phuang(a)redhat.com ReportedBy: mjg(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: --- If the ~/.config/ibus/bus directory doesn't exist, any gtk app will wake up once per second in an attempt to add a notify on it. The directory should be automatically created to work around this. -- 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.

11 years, 3 months

1
7
0 / 0

[Fedora-i18n-bugs] [Bug 771578] New: Gap between vowel signs ('=?UTF-8?Q?=E0=A7=87?=', '=?UTF-8?Q?=E0=A6=BE?=', '=?UTF-8?Q?=20=E0=A6=BF?=') and letters when in combination is more.

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Gap between vowel signs ('ে', 'া', ' ি') and letters when in combination is more. https://bugzilla.redhat.com/show_bug.cgi?id=771578 Summary: Gap between vowel signs ('ে', 'া', ' ি') and letters when in combination is more. Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: unspecified Component: lohit-assamese-fonts AssignedTo: psatpute(a)redhat.com ReportedBy: ngoswami(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Created attachment 550621 --> https://bugzilla.redhat.com/attachment.cgi?id=550621 Combinations of 3 vowels with letters Description of problem: The gap between vowel signs ('ে', 'া', 'ি') and letters when in combination is more than actual. The vowel sign 'ে' always sits a bit more towards left. Same is the problem with 'া' and 'ি'. The gap should be reduced. The gaps become more prominent and the join appears broken when letters are bold. I am attaching documents containing the in general combinations of letters with 'ে', 'া' and 'ি' both in regular and bold for reference. -- 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.

11 years, 3 months

1
5
0 / 0

[Fedora-i18n-bugs] [Bug 799565] New: Lohit Malayalam font does not have support for 0D4E MALAYALAM LETTER DOT REPH

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Lohit Malayalam font does not have support for 0D4E MALAYALAM LETTER DOT REPH https://bugzilla.redhat.com/show_bug.cgi?id=799565 Summary: Lohit Malayalam font does not have support for 0D4E MALAYALAM LETTER DOT REPH Product: Fedora Version: 16 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: lohit-malayalam-fonts AssignedTo: psatpute(a)redhat.com ReportedBy: samjnaa(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Description of problem: It was announced (https://www.redhat.com/archives/lohit-devel-list/2012-February/msg00011.html) that the latest 2.5.1 version Lohit fonts support latest Unicode 6.0 characters. Especially Malayalam was also mentioned. However I find that the Lohit Malayalam 2.5.1 release downloadable from https://fedorahosted.org/releases/l/o/lohit/lohit-malayalam-ttf-2.5.1.tar.gz does NOT provide support for 0D4E MALAYALAM LETTER DOT REPH. As this is one of the three Malayalam characters encoded for Unicode 6.0 (see http://www.unicode.org/Public/UNIDATA/DerivedAge.txt and search for 0D4E) it should also be supported. [The other two characters are provided but 0D3A has a wrong glyph which I have reported as bug 798870.] Version-Release number of selected component (if applicable): 2.5.1 Steps to Reproduce: 1. Install Lohit Malayalam 2.5.1 font. 2. Try to use 0D4E MALAYALAM LETTER DOT REPH Actual results: This character is not available. Expected results: This character was encoded to support the old Malayalam orthography. As such it should be made available for full Unicode 6.0 (or 6.1) support. Additional info: You might need to do some smart font programming to position the dot reph correctly. Note that this character is a special rendering character (hence the dotted box around it in the code chart http://www.unicode.org/charts/PDF/U0D00.pdf). The special rendering is that it should be placed on top of the character *following* it. See the original proposal bottom of page 3 and top of page 4. I think the e-Malayalam OTC font (http://www.aai.uni-hamburg.de/indtib/INDOLIPI/Malayalam.zip) has pre-composed glyphs using this character on top of other consonants which might help you in positioning this character. Note that most often it is found with doubled consonants (i.e. DOT_REPH + GA + VIRAMA + GA etc) so you will have to be able to position this character above stacked consonant clusters. I hope this is sufficient feedback for supporting this character which is important for old Malayalam orthography. -- 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.

11 years, 3 months

1
25
0 / 0

[Fedora-i18n-bugs] [Bug 648358] New: Devanagari Northern Variant for Lohit Devanagari

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Devanagari Northern Variant for Lohit Devanagari https://bugzilla.redhat.com/show_bug.cgi?id=648358 Summary: Devanagari Northern Variant for Lohit Devanagari Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: lohit-devanagari-fonts AssignedTo: psatpute(a)redhat.com ReportedBy: ujjwol(a)fedoraproject.org QAContact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Created attachment 456793 --> https://bugzilla.redhat.com/attachment.cgi?id=456793 Chandas Uttara Sahadeva and Lohit Devangari Description of problem: The Lohit Devanagari currently uses the most popular variant - the southern variant of devanagari. But being the default font of fedora a popular os, it should also support the northern variant of devangari. This requires additions of newer glyph for: अ आ ओ औ ऋ ॠ ण झ क्ष My goal by asking this feature is to make Lohit Devanagari a full featured Devanagari font. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: I have attached the screenshot showing it in Chandas/Uttara - a GPL'ed font containing Northern Variant, and a free font Sahadeva containing Northern variant along with Lohit Hindi. Hope this will help. -- 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.

11 years, 4 months

1
11
0 / 0

[Fedora-i18n-bugs] [Bug 603958] New: gdm kbd layout setting should add US layout by default for layouts without Latin characters

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: gdm kbd layout setting should add US layout by default for layouts without Latin characters https://bugzilla.redhat.com/show_bug.cgi?id=603958 Summary: gdm kbd layout setting should add US layout by default for layouts without Latin characters Product: Red Hat Enterprise Linux 6 Version: 6.1 Platform: All URL: https://www.redhat.com/archives/fedora-devel-list/2008 -December/msg00047.html OS/Version: Linux Status: NEW Severity: high Priority: high Component: gdm AssignedTo: jmccann(a)redhat.com ReportedBy: rstrode(a)redhat.com QAContact: desktop-bugs(a)redhat.com CC: petersen(a)redhat.com, jmccann(a)redhat.com, rstrode(a)redhat.com, atigro(a)ya.ru, tfujiwar(a)redhat.com, pnemade(a)redhat.com, shamardin(a)gmail.com, atorkhov(a)gmail.com, peter.hutterer(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, TBomBM3879(a)gmail.com, sergey.rudchenko(a)gmail.com, tim623(a)gmail.com Depends on: 474010 Blocks: 474014 Classification: Red Hat Target Release: --- Clone Of: 474010 +++ This bug was initially created as a clone of Bug #474010 +++ Description of problem: If you select "Russian" keyboard during system installation then gdm is configured to use Russian input for user names and passwords by default. Any language different from english does not make sense for user name, and probably english should be default for passwords. Version-Release number of selected component (if applicable): gdm-2.24.0-12.fc10.i386 How reproducible: always? Steps to Reproduce: 1. install a fresh fedora system using "Russian" keyboard. Don't be afraid, it won't affect the installation since during installation you will have US english layout with this selection anyway. 2. try to enter a login name when you get that far. Actual results: You are entering funny cyrillic characters. Expected results: English, at least for user name and hopefully for password. Additional info: https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00047.... --- Additional comment from TBomBM3879(a)gmail.com on 2009-03-02 18:41:01 EST --- I don't get this bug? If you select the Russian keyboard layout, then that's exactly what you'll get; the Russian layout for the keys on your keyboard. If you are using a US keyboard, then use the US keyboard layout. --- Additional comment from TBomBM3879(a)gmail.com on 2009-03-02 19:54:01 EST --- *** Bug 474011 has been marked as a duplicate of this bug. *** --- Additional comment from shamardin(a)gmail.com on 2009-03-03 00:35:56 EST --- (In reply to comment #1) > I don't get this bug? In case you don't know, Russian layout does not have any of the the latin characters. Unix account names always use English low-case alphabet. Therefore in order to be able to enter a unix account name (this is an expected thing at a login screen, right?) you would like to be able to enter English letters, and you can't if the only keyboard layout available is Russian. Even more, the most common practice, at least in Russia, is not to use Russian layout when entering passwords, but use the English layout; otherwise you often can encounter "there-are-many-encodings" problems. To have a Russian keyboard layout as the only choice at the login prompt as an insane default. Nobody even in Russia would be able to use this default setting. This must be changed. This is an insane and unsuable default. And even if you ignore the login problem, almost every Russian user will install the English keyboard as one of the first actions on a new system, because there are lots of other places where latin letters are used. Some examples are unix command line and web URLs. > > If you select the Russian keyboard layout, then that's exactly what you'll get; > the Russian layout for the keys on your keyboard. > > If you are using a US keyboard, then use the US keyboard layout. And I can tell you even more, Russian keyboard layout is not the only layout with this peculiarity. At least a Greek layout has the same problems. I believe there are other layouts as well. For all these layouts you would like to have: 1. English layout selected as default on the login screen. 2. English layout installed as an alternate layout after logging in. No exceptions. --- Additional comment from shamardin(a)gmail.com on 2009-03-03 00:38:02 EST --- This is not the duplicate of 474011. This bug is about insane default, bug 474011 is about broken layout switching at login. --- Additional comment from tim623(a)gmail.com on 2009-08-04 22:10:41 EDT --- Solving this bug would solve bug 474014 by eliminating the need to "double-switch" (see Description of bug 474014.) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers --- Additional comment from fedora-triage-list(a)redhat.com on 2009-11-18 02:47:49 EST --- This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from petersen(a)redhat.com on 2009-11-24 03:24:00 EST --- I think I can reproduce this with F12 Live: 1. boot F12 Live 2. switch layout to Russia 3. autologin as liveuser 4. observe only "ru" layout installed not "us" as well I think we need to install both for Russian: "us,ru" would probably be better for technical users anyway. Then Shift+Caps_Lock should allow switching "ru" <-> "us". --- Additional comment from petersen(a)redhat.com on 2009-11-24 03:45:11 EST --- Ah I see: if I then logout and change to US kbd layout and login again then the gnome kbd applet shows "us,ru". (Though no xkb toggle for changing layout, eg Shift+Caps_Lock, defined.) I think we need "XX,us" for all layouts that don't provide Latin input, or maybe better checkboxes in the gdm options layout widget to select multiple layouts? --- Additional comment from atigro(a)ya.ru on 2009-11-24 04:26:06 EST --- (In reply to comment #8) > Ah I see: if I then logout and change to US kbd layout > and login again then the gnome kbd applet shows "us,ru". > (Though no xkb toggle for changing layout, > eg Shift+Caps_Lock, defined.) > > I think we need "XX,us" for all layouts that don't > provide Latin input, or maybe better checkboxes > in the gdm options layout widget to select multiple > layouts? Yes, checkboxes (and pre checkboxed items for different languages) is a very, very good idea. But "us" must be the primary layout for non latin. For some other (as cz,us) let it be cz,us. --- Additional comment from tfujiwar(a)redhat.com on 2009-11-25 23:21:48 EST --- Probably I could understand this issue. In the most cases, I would think users could define their keyboard layouts with gnome-keyboard-properties after they log into the session. However it seems this request is to the special keyboard layouts which don't have ASCII chars. They need to type both ASCII and the language chars. Yes, sending multiple layouts could be a solution. However I'd think that selecting one layout on GDM is simple. Probably I think one solution is to configure input method. E.g. A user chooses "ru" on GDM and log into the GNOME session, ibus checks the user's layout, if the layout is found in the predefined list in ibus, ibus provides the "us" layout with Ctrl + Space. If the users could switch "ru" and "us" with the trigger key, probably I think this problem could be resolved and if they want other language layouts, they could use gnome-keyboard-properties. --- Additional comment from shamardin(a)gmail.com on 2009-11-26 02:53:28 EST --- No, you don't get it at all. There is no need to tweak ANYTHING after the log in. And there is no need to provide switching in GDM. It is very simple: after user is logged in any kind of defaults, setups etc. is fine and must be left for the user. But not at the GDM. At the GDM you ALWAYS need to type latin characters. So, if you have selected US keyboard you do not need to change anything for GDM defaults. If you have selected French keyboard you do not need to change anything for GDM defaults. If you have selected Greek keyboard you MUST change default layout in GDM to US. If you have selected Russian keyboard you MUST change default layout in GDM to US. And so on. Not AFTER logging in to GNOME session. Not allowing to switch with more comfort in GDM. Just set the appropriate for the keyboard latin layout in GDM as default, and thats it! --- Additional comment from shamardin(a)gmail.com on 2009-11-26 03:03:56 EST --- And yes, there is another place in the system which needs the same amount of sane defaults, but I'm too lazy right now to open a separate bug. It's gnome-screensaver. If you happen to lock your screen with NO latin layout available to switch to, you will never be able to unlock it. The perfect solution would be something like this: at all places which prompt for system password or login, default selected layout must be appropriate latin layout (US for US keyboard, French for French keyboard, US for Russian keyboard, US for greek keyboard, etc.) --- Additional comment from petersen(a)redhat.com on 2009-11-26 03:47:03 EST --- Ok so there are two issues (1) make sure user can input Latin characters in gdm (2) config good default layouts for desktop Lev is talking about (1). So probably (2) might be moved to another bug even though they might be solvable together. (Using input-methods or ibus for xkb switching might help but Latin layout needs to be base layout for gdm, screensaver, etc.) --- Additional comment from petersen(a)redhat.com on 2009-11-26 03:48:49 EST --- However I think the easiest way to solve (1) is by (2). --- Additional comment from shamardin(a)gmail.com on 2009-11-26 03:52:13 EST --- You cannot solve (2) because what is a 'good default' for the user is up to the user to decide. There will always be dissatisfied with your 'good defaults'. But for the GDM and other login/password prompts there can be only one 'good default': latin layout. --- Additional comment from petersen(a)redhat.com on 2009-11-26 03:54:22 EST --- Taking ru as the example: /usr/share/X11/xkb/symbols/ru doesn't provide Latin input so when using it the layout should be set to "us,ru" and xkb can do layout switching (per window) between us and ru as needed. We are also thinking how ibus can help with this eventually. --- Additional comment from tfujiwar(a)redhat.com on 2009-11-26 04:10:13 EST --- (In reply to comment #11) > default layout in GDM to US. If you have selected Russian keyboard you MUST > change default layout in GDM to US. And so on. Not AFTER logging in to GNOME >From this mention, the Russian users normally select "us" layout in GDM with the physical Russian keyboard but don't select "ru" layout for the user/passwd prompt and they like to switch ru and us layout after log into the session? If we fix this in either GDM or IBus side, probably I think the hard-coded list is needed and it could be done in ibus. --- Additional comment from shamardin(a)gmail.com on 2009-11-26 04:24:49 EST --- (In reply to comment #17) > From this mention, the Russian users normally select "us" layout in GDM with > the physical Russian keyboard but don't select "ru" layout for the user/passwd > prompt and they like to switch ru and us layout after log into the session? Yes, normally Russian users have "us" layout in GDM with a physical Russian keyboard, and after logging into the session they usually have two layouts with switching between them, "us" and "ru" (typically a layout variant which was named "ru-winkeys" some time ago). Which one is the default depends on the user's main activity. Those who often type commands usually prefer "us" layout as the default, while those who use generally mail-browser-office applications often prefer "ru" layout as the default, but usually all Russian users have two layouts configured with switching. For those of you who have no idea what does 'physical Russian keyboard' look like, I will attach a picture to this bug. Please notice that the keys have two layouts printed on them: US (upper characters on letter keys, left column of characters on symbols and numbers) and Russian (lower characters on letter keys, right column of characters on symbols and numbers). --- Additional comment from shamardin(a)gmail.com on 2009-11-26 04:25:34 EST --- Created an attachment (id=373944) --> (https://bugzilla.redhat.com/attachment.cgi?id=373944) Photo of a physical russian keyboard, showing two layouts printed on keys. --- Additional comment from shamardin(a)gmail.com on 2009-11-26 04:29:32 EST --- Created an attachment (id=373945) --> (https://bugzilla.redhat.com/attachment.cgi?id=373945) Photo of a physical greek keyboard, showing two layouts printed on keys. --- Additional comment from petersen(a)redhat.com on 2009-11-26 20:36:39 EST --- http://wikipedia.org/wiki/Keyboard_layout What is the default layout on Windows? Probably Russian? We have to have default... :) And what should it be on a Linux desktop? For all Asian languages we currently default to Latin input and users have to turn on the input-method for native input. So to me it seems natural to do the same for xkb layouts. I think this is might be ok for Fedora's current user audience, but with long term proliferation we may need to rethink. --- Additional comment from petersen(a)redhat.com on 2009-11-26 20:43:38 EST --- Or how would you decide when to switch layout immediately in gdm and when not? Eg AZERTY (French) or Dvorak users would not want gdm to delay changing layout until after login. --- Additional comment from shamardin(a)gmail.com on 2009-11-27 00:22:00 EST --- On windows if you select Russian keyboard, the system is configured to have two layouts, US and Russian with layout switching and Russian as default, even at login prompt. Windows allows unicode login names (and russian login names become more and more common for home users). POSIX does not. There is absolutely no point to have a non-latin layout as default when you need to enter a POSIX login! --- Additional comment from peter.hutterer(a)redhat.com on 2009-11-27 00:51:55 EST --- how about the following idea: gdm provides an on-screen keyboard. this keyboard provides the layout selected by the user (russian in this case) but also "Switch to US layout" button. Hitting this button changes _both_ the virtual keyboard and the physical keyboard to a us layout. Hitting the "back" button (or whatever) changes back to the previous method. This is an idea only, with no code to back it up but it solves a few issues: - users without a keyboard can log in using the virtual keyboard - users with a non-ascii layout can switch to an ascii-layout if needed - no "magic" layout switching using possibly unknown keyboard shortcuts - if the layout is changed to US, the visual representation shows what the physical keyboard now does. for those not used to the US layout, this provides an overview of what the keyboard does now. --- Additional comment from shamardin(a)gmail.com on 2009-11-27 01:37:45 EST --- (In reply to comment #24) > how about the following idea: > > gdm provides an on-screen keyboard. this keyboard provides the layout selected > by the user (russian in this case) but also "Switch to US layout" button. > Hitting this button changes _both_ the virtual keyboard and the physical > keyboard to a us layout. Hitting the "back" button (or whatever) changes back > to the previous method. I have a better idea. Let's make Russian layout with big convinient button to switch to US as default for US Keyboard. The whole point is THERE ARE ABSOLUTELY NO CASES WHEN YOU NEED A RUSSIAN LAYOUT AT LOGIN PROMPT!!! You do not need switching, you do not need more convinient switching, all you need is a f-----g latin layout as default! > This is an idea only, with no code to back it up but it solves a few issues: > - users without a keyboard can log in using the virtual keyboard Users without a keyboard must hit "change layout" button first. Great. > - users with a non-ascii layout can switch to an ascii-layout if needed And users with non-latin layout must hit "change layout" button first. > - no "magic" layout switching using possibly unknown keyboard shortcuts But they can see that big button clearly. > - if the layout is changed to US, the visual representation shows what the > physical keyboard now does. for those not used to the US layout, this provides > an overview of what the keyboard does now. And we will have a shiny virtual keyboard, great! --- Additional comment from sergey.rudchenko(a)gmail.com on 2009-12-05 00:32:12 EST --- My 2 cents. GDM should know whether it works on a POSIX system and enable ONLY latin keyboard layout for it's login input field. >From the other hand, passwords CAN contain non-latin characters so it's worth to have an ability to type them. I propose to add a layout indicator (pretty like gnome-panel applet, but cutted) in right of the password input box. For those who have a non-latin password. The layout list for the switcher should be filled with the us+system default keyboard (e.g. us,ru). Notice, the latin layout should go first, because most of users are careful enough to use a latin password. And finally, I think the proposed switcher should be hidden if the alternative layout contains all the latin characters (GDM would need some library to determine that?). The switcher widget itself must solve the problem for users unfamiliar with the default layout toggle shortcuts. --- Additional comment from tfujiwar(a)redhat.com on 2010-02-19 05:06:11 EST --- Created an attachment (id=395063) --> (https://bugzilla.redhat.com/attachment.cgi?id=395063) Patch for gdm-common.h, gdm-session-direct.c, gdm-layouts.c Sorry for dispatching the issue. I thought to fix this in IM side but there are several problems; one is a design issue in either ibus Linpus version or ibus-xkbc and another is IM should be disabled in password dialog for lookup table. Now I'm back to GDM for this issue. When I see system-config-keyboard, it has the hard-coded table in /usr/lib/python2.6/site-packages/system_config_keyboard/keyboard_models.py. Probably it would be a good idea to have the static data instead of parsing xkb directory. I picked up "ara", "bg", "cz", "dev", "gr", "gur", "in", "mkd", "ru", "ua" from the keyboard_models.py. This patch assigns Ctrl+Shift to switch the layouts of "us" and the original on both GDM login and logged session. system-config-keyboard assigns Shift_L+Shift_R but I guess some keyboards might not have two shifts. It still needs to change gnome-settings-daemon but almost works fine in my test. --- Additional comment from tfujiwar(a)redhat.com on 2010-02-23 04:09:24 EST --- Created an attachment (id=395671) --> (https://bugzilla.redhat.com/attachment.cgi?id=395671) Patch for gdm-common.h, gdm-session-direct.c, gdm-layouts.c Revised the patch to use gconf and put a label "Ctrl + Shift toggles layouts" in prompt when you select the non-ASCII layout. --- Additional comment from tfujiwar(a)redhat.com on 2010-02-23 21:58:03 EST --- Created an attachment (id=395876) --> (https://bugzilla.redhat.com/attachment.cgi?id=395876) Patch for gdm page.ui The patch is applied over the internal patch gdm-multistack.patch . --- Additional comment from tfujiwar(a)redhat.com on 2010-02-23 21:59:54 EST --- Created an attachment (id=395877) --> (https://bugzilla.redhat.com/attachment.cgi?id=395877) Patch for gnome-settings-daemon gsd-keyboard-xkb.c gnome-settings-daemon can load the group layouts with this patch. --- Additional comment from tfujiwar(a)redhat.com on 2010-02-23 22:39:17 EST --- Working on the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=610903 --- Additional comment from fedora-triage-list(a)redhat.com on 2010-03-15 08:11:32 EDT --- This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- 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.

11 years, 4 months

1
8
0 / 0

[Fedora-i18n-bugs] [Bug 810183] New: Input method for the locale logged into must be enabled by default

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Input method for the locale logged into must be enabled by default https://bugzilla.redhat.com/show_bug.cgi?id=810183 Summary: Input method for the locale logged into must be enabled by default Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: ibus AssignedTo: tfujiwar(a)redhat.com ReportedBy: apeter(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: tfujiwar(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com Classification: Fedora Story Points: --- Type: Bug Regression: --- Mount Type: --- Documentation: --- Created attachment 575350 --> https://bugzilla.redhat.com/attachment.cgi?id=575350 Default ibus setting showing only English as input method Description of problem: When a user logins to a particular locale, say Malayalam, ibus has only English input method. We need to add the Malayalam input method manually to enable Malayalam. Version-Release number of selected component (if applicable): ibus-1.4.99.20120304-3.fc17.i686 How reproducible: Always Steps to Reproduce: 1. Log into malayalam locale. 2. Click on ibus icon on the panel at the right corner. 3. You can see only English input method is displayed. Actual results: When you reproduce the above steps 1 and 2, only English input method is displayed. (Screen shot "ibus settings for ml locale" attached) Expected results: When you reproduce the above steps 1 and 2, both English and atleast one of the Malayalam input methods must be displayed. (Screen shot "Expected ibus settings for ml locale" attached) Additional info: -- 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.

11 years, 6 months

1
4
0 / 0

[Fedora-i18n-bugs] [Bug 756270] New: libpinyin cannot remember user's input

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: libpinyin cannot remember user's input https://bugzilla.redhat.com/show_bug.cgi?id=756270 Summary: libpinyin cannot remember user's input Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: libpinyin AssignedTo: pwu(a)redhat.com ReportedBy: wshen(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com Classification: Fedora Story Points: --- Type: --- Description of problem: when inputing "我是一只鱼", the libpinyin cannot remember the phrase after I input several times. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- 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.

11 years, 6 months

1
2
0 / 0

[Fedora-i18n-bugs] [Bug 514110] New: [ta_IN] Tamil collation rules are not working in other locales

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [ta_IN] Tamil collation rules are not working in other locales https://bugzilla.redhat.com/show_bug.cgi?id=514110 Summary: [ta_IN] Tamil collation rules are not working in other locales Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: glibc AssignedTo: schwab(a)redhat.com ReportedBy: psatpute(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: jakub(a)redhat.com, santhosh.thottingal(a)gmail.com, fedora-i18n-bugs(a)redhat.com, schwab(a)redhat.com Estimated Hours: 0.0 Classification: Fedora Target Release: --- Description of problem: ta_IN collation rules are not working, when we select other locale say en_US.UTF-8 Version-Release number of selected component (if applicable): glibc-common-2.10.90-7.1 How reproducible: every time Steps to Reproduce: 1. select en_US locale 2. try to sort Tamil characters 3. Actual results: sorting is not working Expected results: It should be sorted as per collation rule Additional info: This is happening due to ta_IN collation rules written in ta_IN locale file, and these rules are not available to outside locale. We should move these collation table to iso14651_t1_common(common to most of the locale), so it will be available to other locale as well and tamil sorting will work while selecting any locale -- 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.

11 years, 6 months

1
28
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs April 2012