i18n-bugs November 2018

i18n-bugs@lists.fedoraproject.org

2 participants
61 discussions

[Fedora-i18n-bugs] [Bug 1647316] New: unable to change input mode from the top right dropdown menu
by bugzilla＠redhat.com 08 Nov '18

08 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1647316 Bug ID: 1647316 Summary: unable to change input mode from the top right dropdown menu Product: Fedora Version: 29 Component: ibus Severity: high Assignee: tfujiwar(a)redhat.com Reporter: ksugawar(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Created attachment 1502858 --> https://bugzilla.redhat.com/attachment.cgi?id=1502858&action=edit screenshot Description of problem: When I try to change input mode from the top right dropdown menu (see the attached screenshot), I should be able to click on the line that says "Input Mode", and the list of input modes expands to show all the modes from which I can select one. Now, even if I click on the "Input Mode" line, it does nothing so I cannot switch one mode to another within an IME (the screenshot is taken when ibus-kkc is active, but the same thing happens with ibus-mozc as well). Version-Release number of selected component (if applicable): ibus-1.5.19-7.fc29.x86_64 ibus-kkc-1.5.22-10.fc29.x86_64 ibus-mozc-2.23.2815.102-2.fc29.x86_64 How reproducible: Always. Steps to Reproduce: 1. Add Japanese input methods such as ibus-kkc and ibus-mozc 2. Activate the Japanese input method 3. Try to change Input Mode from the top right menu Actual results: Unable to switch between input modes Expected results: Able to switch from an input mode to another Additional info: Farther investigation revealed that the list of input modes *is* expanded but it fails to be rendered on the screen. If I click the right location where an input mode (e.g. Hiragana) is normally located after I click the "Input Mode", I can choose the input mode (quite difficult to use). -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Fedora-i18n-bugs] [Bug 1405539] changing the default keyboard layout changes also disk decryption in plymouth , but only after kernel update, long after
by bugzilla＠redhat.com 07 Nov '18

07 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1405539 Kamil Páral <kparal(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |CommonBugs -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1646688] New: bad hinting instructions from bug in ttfautohint
by bugzilla＠redhat.com 07 Nov '18

07 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1646688 Bug ID: 1646688 Summary: bad hinting instructions from bug in ttfautohint Product: Fedora Version: 29 Component: lohit-devanagari-fonts Assignee: petersen(a)redhat.com Reporter: htl10(a)users.sourceforge.net QA Contact: extras-qa(a)fedoraproject.org CC: extras-qa(a)fedoraproject.org, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, i(a)cicku.me, petersen(a)redhat.com, psatpute(a)redhat.com, sshedmak(a)redhat.com, yselkowi(a)redhat.com You will need to use a bug-fixed ttfautohint to re-generate the lohit devanagari font. Version affected: lohit-devanagari-fonts-2.95.4-5.fc29.noarch +++ This bug was initially created as a clone of Bug #1646687 +++ Description of problem: This was discussed in freetype-devel for much of early October under the thread "rendering issues with xpdf (and other viewers)". upstream patch (this was applied after 1.8.2) - you will need to push this to all the fonts affected - in particular, lohit-devanagari-fonts-2.95.4-5.fc29.noarch commit f18b7c859c92111446ca991743dd709e347d0301 (HEAD -> master, origin/master, origin/HEAD) Author: Werner Lemberg <wl(a)gnu.org> Date: Sat Oct 6 09:04:35 2018 +0200 tafpgm.c: Fix stem width offset handling in storage area. Problem reported by Hin-Tak Leung <htl10(a)users.sourceforge.net>. Version-Release number of selected component (if applicable): ttfautohint-1.8.1-4.fc29.x86_64 How reproducible: Always Steps to Reproduce: 1. "ftview 53 /usr/share/fonts/lohit-devanagari/Lohit-Devanagari.ttf" 2. navigate to glyph idx 472 with F9/F10/F11/F12 3. use up/down arrow key to see that the circular ring of 12 dots disappears and becomes 3 dots, etc. Actual results: 3 dots and fewer than 12 dots for many sizes below about 60. Expected results: 12 dots for idx 472 at all sizes. Additional info: This was discussed on freetype-devel for much of early October under 'rendering issues with xpdf (and other viewers)' -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Fedora-i18n-bugs] [Bug 1646848] New: ibus-gtk3 should not require ibus
by bugzilla＠redhat.com 06 Nov '18

06 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1646848 Bug ID: 1646848 Summary: ibus-gtk3 should not require ibus Product: Red Hat Enterprise Linux 8 Version: 8.0 Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: tfujiwar(a)redhat.com QA Contact: qe-i18n-bugs(a)redhat.com CC: eng-i18n-bugs(a)redhat.com, extras-qa(a)fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Depends On: 1643864 Group: redhat +++ This bug was initially created as a clone of Bug #1643864 +++ ibus-gtk[2|3] have depended ibus not to break the API compatibility between ibus and ibus-libs since some applications could require ibus-libs only without ibus. Actually ibus-libs does not require ibus but needs to keep the same version between ibus and ibus-libs. Now I think 'Conflicts:' tag is the right usage for the purpose and will delete 'Requires: ibus' in ibus-gtk* and use 'Conflicts: ibus < version' in ibus-libs. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1643864 [Bug 1643864] ibus-gtk3 should not require ibus -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1579464] New: update breaks boot
by bugzilla＠redhat.com 05 Nov '18

05 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1579464 Bug ID: 1579464 Summary: update breaks boot Product: Fedora Version: rawhide Component: fontconfig Severity: high Assignee: tagoh(a)redhat.com Reporter: contactopublico57(a)bol.com.br QA Contact: extras-qa(a)fedoraproject.org CC: ajax(a)redhat.com, alexl(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, john.j5live(a)gmail.com, mclasen(a)redhat.com, pnemade(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, tagoh(a)redhat.com Description of problem:dnf update to fontconfig-2.13.0-4.fc29.x86_64 produces boot failure. Additional package updates produce boot failure as noted below. Version-Release number of selected component (if applicable): fontconfig-2.13.0-4.fc29.x86_64 How reproducible: dnf update fontconfig-2.13.0-4.fc29.x86_64 Steps to Reproduce: 1.dnf system update 2. 3. Actual results: dnf update installs fontconfig-2.13.0-4.fc29.x86_64 reboot results in boot failure prior to loading lightdm-1.25.2-1.fc29.x86_64 with mate-desktop-1.20.1-5.fc29.x86_64. Expected results: boot to lightdm login manager/mate desktop Additional info: same behavior with dnf update of following additional packages: harfbuzz-1.7.5-3.fc29.x86_64 harfbuzz-icu-1.7.5-3.fc29.x86_64 Please advise if you need a separate bug report for the harfbuzz packages. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Fedora-i18n-bugs] [Bug 1632981] New: Inputting hangul marchs in place in gnome-terminal
by bugzilla＠redhat.com 04 Nov '18

04 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1632981 Bug ID: 1632981 Summary: Inputting hangul marchs in place in gnome-terminal Product: Fedora Version: 29 Component: ibus-hangul Severity: medium Assignee: pwu(a)redhat.com Reporter: sangu.fedora(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Description of problem: Inputting hangul marchs in place in gnome-terminal Version-Release number of selected component (if applicable): 1.5.1-2.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. launch gnome-terminal 2. input hangul (switch hangul, click any keys) 3. Actual results: click rrrrrr (with ibus-hangul) Expected results: click rrrrrr (with ibus-hangul) ㄲㄲㄲㄲ Additional info: ibus-1.5.19-4.fc29.x86_64 gnome-shell-3.30.0-8.fc29.x86_64 xorg-x11-server-Xwayland-1.20.1-2.fc29.x86_64 libwayland-server-1.16.0-1.fc29.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

1 23

[Fedora-i18n-bugs] [Bug 1632646] New: Not able to commit Japanese characters by hitting enter key in libreoffice applications /nautilus
by bugzilla＠redhat.com 04 Nov '18

04 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1632646 Bug ID: 1632646 Summary: Not able to commit Japanese characters by hitting enter key in libreoffice applications/nautilus Product: Fedora Version: 29 Component: ibus-kkc Keywords: i18n Assignee: dueno(a)redhat.com Reporter: bbarve(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Description of problem: in F29, trying to input using Japanese(kana kanji) in oowriter. when I start typing in Japanese(Hiragana) and press space for candidates suggestion, I get the candidates window as expected. However if I select a candidate and hit enter to commit that word, no input is entered. Experiencing this with libreoffice applications and nautilus. Version-Release number of selected component (if applicable): F29 ibus-1.5.19-4.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. open oowriter 2. using kana kanji input method, start typing any Japanese input. 3. press space for candidate suggestion window. 4. from the candidate suggestion window, select a candidate at any position and hit enter to commit it. Actual results: No input is entered. Expected results: The input should get committed. Additional info: The input is working properly in gedit. It works in libreoffice as well if direct input is entered by hitting enter, without candidate window. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Fedora-i18n-bugs] [Bug 1644475] New: [abrt] ibus-setup: join(): posixpath.py:80:join: TypeError: expected str, bytes or os.PathLike object, not NoneType
by bugzilla＠redhat.com 02 Nov '18

02 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1644475 Bug ID: 1644475 Summary: [abrt] ibus-setup: join(): posixpath.py:80:join:TypeError: expected str, bytes or os.PathLike object, not NoneType Product: Fedora Version: 29 Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: hi(a)nikhiljha.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Description of problem: Installed ibus, ran ibus-config (but ibus-config uses the current python, not the system python like it should) so I ran it with system python with /usr/bin/python3 /usr/share/ibus/setup/main.py and it crashed. Version-Release number of selected component: ibus-setup-1.5.19-4.fc29 Additional info: reporter: libreport-2.9.6 cmdline: /usr/bin/python3 /usr/share/ibus/setup/main.py crash_function: join exception_type: TypeError executable: /usr/share/ibus/setup/main.py interpreter: python3-3.7.1-1.fc29.x86_64 kernel: 4.18.16-300.fc29.x86_64 runlevel: N 5 type: Python3 uid: 1000 Truncated backtrace: posixpath.py:80:join:TypeError: expected str, bytes or os.PathLike object, not NoneType Traceback (most recent call last): File "/usr/share/ibus/setup/main.py", line 698, in <module> setup = Setup() File "/usr/share/ibus/setup/main.py", line 115, in __init__ self.__init_ui() File "/usr/share/ibus/setup/main.py", line 404, in __init_ui self.__checkbutton_auto_start.set_active(self.__is_auto_start()) File "/usr/share/ibus/setup/main.py", line 654, in __is_auto_start "share/applications/ibus.desktop") File "/usr/lib64/python3.7/posixpath.py", line 80, in join a = os.fspath(a) TypeError: expected str, bytes or os.PathLike object, not NoneType Local variables in innermost frame: a: None p: ('share/applications/ibus.desktop',) -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Fedora-i18n-bugs] [Bug 1644500] Can't upgrade due to libxfconf-0.so.2 requirement
by bugzilla＠redhat.com 01 Nov '18

01 Nov '18

1 0

[Fedora-i18n-bugs] [Bug 1547337] New: ibus-kkc won' t let me add words to dictionary in kana mode
by bugzilla＠redhat.com 01 Nov '18

01 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1547337 Bug ID: 1547337 Summary: ibus-kkc won't let me add words to dictionary in kana mode Product: Fedora Version: 27 Component: ibus-kkc Severity: medium Assignee: dueno(a)redhat.com Reporter: maverick6664(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Description of problem: In kana mode which I like, KKC won't let me add words to the dictionary, while in Roma-ji mode, it works fine. Version-Release number of selected component (if applicable): I use Fedora 27, but other version should be applied to. How reproducible: Always. Steps to Reproduce: 1.Select a word (usually kanji word) with mouse. 2.Hit Alt+r (nothing happens then) 3.Enter its reading Actual results: No words are recorded. Expected results: Words are added to the dictionary. Additional info: It works in Romaji-mode. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs November 2018