July 2022 - i18n-bugs - Fedora Mailing-Lists

[Bug 2060988] New: ibus lookup table almost always badly positioned in Plasma(Wayland)

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2060988 Bug ID: 2060988 Summary: ibus lookup table almost always badly positioned in Plasma(Wayland) Product: Fedora Version: 36 Status: NEW Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: mfabian(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 Target Milestone: --- Classification: Fedora Created attachment 1864184 --> https://bugzilla.redhat.com/attachment.cgi?id=1864184&action=edit Video showing that the lookup table usually pops up far away from the cursor positon in gedit, kwrite, konsole, LibreOfficeWriter Fedora-Workstation-Live-x86_64-36-20220216.n.0.iso installed in qemu-kvm with all current updates. The ibus lookup table appears at weird positions far away from the cursor almost always on Plasma (Wayland). I tested: - gedit - kwrite - konsole - LibreOffice writer - xterm For xterm the lookup table appears where it should, close to the cursor position. For the others the lookup table almost always appears far away from the cursor position. See attached video. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2060988

1 week, 3 days

1
9
0 / 0

[Bug 2060102] New: Remove libdb dependency

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2060102 Bug ID: 2060102 Summary: Remove libdb dependency Product: Fedora Version: rawhide Status: NEW Component: libpinyin Severity: high Assignee: pwu(a)redhat.com Reporter: fjanus(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com, robinlee.sysu(a)gmail.com Target Milestone: --- Classification: Fedora Since there is a long-term effort to remove all libdb dependencies I would like to find out solution also for libpinyin. Libdb was marked as deprecated in Fedora by change[2] and it was also deprecated in RHEL9[1]. Libdb is currently many many years without any update. So it`s quite old code without upstream support. [1] https://access.redhat.com/articles/6464541 [2] https://fedoraproject.org/wiki/Changes/Libdb_deprecated -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2060102

3 weeks, 4 days

1
3
0 / 0

[Bug 2076596] New: The KDE ibus panel does not work as expected.

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2076596 Bug ID: 2076596 Summary: The KDE ibus panel does not work as expected. Product: Fedora Version: 36 Status: NEW Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: lruzicka(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 Target Milestone: --- Classification: Fedora Created attachment 1873514 --> https://bugzilla.redhat.com/attachment.cgi?id=1873514&action=edit The ibus panel with incorrect layout. Description of problem: I have freshly installed KDE Live 20220418 and made following settings during the installation: * System language is English. * Keyboard layout is Czech. After the installation, the keyboard is correctly laid out to "czech" and uses the correct czech mappings. When I check for the system settings using `localectl status`, I get the same result: === System Locale: LANG=en_US.UTF-8 VC Keymap: cz X11 Layout: cz === However, when I log into the KDE session, the IBUS-panel shows incorrectly "EN", but the layout is not English and even when I specifically select it using the panel, it does not have any influence. Also, when I use the panel to add other languages, it does not affect the system layout which is used for the KDE session, as well as for applications (kwrite, konsole), which remains "czech" all the time. Version-Release number of selected component (if applicable): ibus-1.5.26-3 KDE Plasma 5.24.4 How reproducible: Always Steps to Reproduce: 1. Install KDE Live with non-english layout (as the only one) 2. Log into the newly installed session. 3. See if ibus-panel shows the correct layout. 4. Try using ibus-panel to modify keyboard layout in the KDE session. Actual results: ibus-panel cannot modify keyboard layout Expected results: ibus-panel should be able to modify keyboard layout or should not be the default method to do so. Additional info: See screenshot -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2076596

1 month, 2 weeks

1
39
0 / 0

[Fedora-i18n-bugs] [Bug 1936817] New: [abrt] kasumi-unicode: emission_find(): kasumi-unicode killed by SIGSEGV

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1936817 Bug ID: 1936817 Summary: [abrt] kasumi-unicode: emission_find(): kasumi-unicode killed by SIGSEGV Product: Fedora Version: 34 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:44f05d41fea2e8a472e511e723c030f064b80150;VAR IANT_ID=workstation; Component: kasumi Assignee: tagoh(a)redhat.com Reporter: mfabian(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora Version-Release number of selected component: kasumi-unicode-2.5-33.fc34 Additional info: reporter: libreport-2.14.0 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service cmdline: kasumi-unicode crash_function: emission_find executable: /usr/bin/kasumi-unicode journald_cursor: s=4812fe31419f4a0d9519537873c0b262;i=1d75b;b=e33e48f83165443e996e9352116d67f6;m=a1416f520;t=5bd16d16bd6c8;x=215dd7f338688f54 kernel: 5.11.3-300.fc34.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 emission_find at ../gobject/gsignal.c:893 #4 gtk_widget_dispose at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkwidget.c:12162 #7 _gtk_header_bar_update_window_buttons at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkheaderbar.c:474 #8 g_cclosure_marshal_VOID__OBJECTv at ../gobject/gmarshal.c:1910 #9 _g_closure_invoke_va at ../gobject/gclosure.c:873 #12 gtk_widget_propagate_hierarchy_changed_recurse at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkwidget.c:9995 #13 _gtk_widget_propagate_hierarchy_changed at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkwidget.c:10037 #14 gtk_widget_set_parent at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkwidget.c:9653 #15 gtk_window_set_titlebar at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkwindow.c:4234 #16 _gtk_builder_add at /usr/src/debug/gtk3-3.24.26-1.fc34.x86_64/gtk/gtkbuilder.c:906 -- You are receiving this mail because: You are on the CC list for the bug.

1 month, 2 weeks

1
5
0 / 0

[Bug 2063714] New: serif:lang=ja falls back to Droid Sans instead of Noto Sans CJK JP

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2063714 Bug ID: 2063714 Summary: serif:lang=ja falls back to Droid Sans instead of Noto Sans CJK JP Product: Fedora Version: 36 Status: NEW Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com, fonts-bugs(a)lists.fedoraproject.org, gnome-sig(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com, pnemade(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: In Fedora 36 when google-noto-serif-cjk-ttc-fonts is not installed fontconfig seems to fall back to google-droid-sans-fonts rather than google-noto-sans-cjk-ttc-fonts. This might be related to/caused by bug 517789? How reproducible: 100% Steps to Reproduce: 1. boot Fedora Live image 2. fc-match serif:lang=ja Actual results: 2. DroidSansJapanese.ttf: "Droid Sans" "Regular" Expected results: 2. NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular" Additional info: I get the same result with your older copr repo applied F35 fwiw. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2063714

1 month, 2 weeks

1
6
0 / 0

[Bug 2068726] New: Culmus Hebrew fonts aren't usable by TeXLive after installation

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2068726 Bug ID: 2068726 Summary: Culmus Hebrew fonts aren't usable by TeXLive after installation Product: Fedora Version: 35 Status: NEW Component: culmus-fonts Assignee: pnemade(a)redhat.com Reporter: nikita(a)leshenko.net QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pnemade(a)redhat.com, psatpute(a)redhat.com, vishalvijayraghavan(a)gmail.com Target Milestone: --- Link ID: Red Hat Bugzilla 1919932 Classification: Fedora Description of problem: On a clean Fedora 35 after installing texlive, babel-hebrew, and tex-fonts-hebrew, I can't use pdflatex to render a Hebrew document. Version-Release number of selected component (if applicable): texlive 9:2021-48.fc35 texlive-babel-hebrew 9:svn30273.2.3h-48.fc35 tex-fonts-hebrew 0.1-35.fc35 How reproducible: Always Steps to Reproduce: 1. Start a new Fedora 35 container: podman run -it fedora:35 2. dnf install texlive texlive-babel-hebrew tex-fonts-hebrew 3. Try to render hello.tex document listed below (this is a basic Hebrew document) using pdflatex (pdflatex hello.tex). \documentclass{article} \usepackage[utf8x]{inputenc} \usepackage[english,hebrew]{babel} \begin{document} שלום! \end{document} Actual results: Blank PDF Expected results: PDF with Hebrew text Additional info: On Fedora 33 this document caused an error, on Fedora 35 something changed and the error no longer appears, but the result is a bad document. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2068726

2 months

1
3
0 / 0

[Bug 2015149] New: Candidate lists shown in gnome on-screen keyboard are not hidden/closed when they should

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2015149 Bug ID: 2015149 Summary: Candidate lists shown in gnome on-screen keyboard are not hidden/closed when they should Product: Fedora Version: 34 Status: NEW Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: mfabian(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 Target Milestone: --- Classification: Fedora Created attachment 1834251 --> https://bugzilla.redhat.com/attachment.cgi?id=1834251&action=edit Video showing the problem [mfabian@fedora ~]$ cat /etc/fedora-release Fedora release 35 (Thirty Five) [mfabian@fedora ~]$ rpm -q ibus ibus-1.5.25-4.fc35.x86_64 [mfabian@fedora ~]$ rpm -q gnome-shell gnome-shell-41.0-4.fc35.x86_64 [mfabian@fedora ~]$ Running in qemu-kvm with all current updates. Gnome Xorg session. Input methods sometimes show candidate lists and sometimes hide or close them again. For example, when a candidate is committed the candidate list usually disappears. The candidate list shown on top of the gnome on-screen keyboard should behave the same way. Always when the “normal” candidate list would disappear, the candidate list on top of the Gnome on-screen keyboard should disappear as well. But this is not the case. See the attached video. The video shows using these input methods: - ibus-libpinyin (Chinese (Intelligent Pinyin)) - ibus-kkc (Japanese (Kana Kanji)) - ibus-typing-booster (Other (Typing Booster)) - ibus-anthy (Japanese (Anthy)) *Only* if ibus-anthy is used, the candidate list disappears reliably when the candidate currently shown in the preedit is commit by clicking on the "Return" key on the on-screen keyboard. When using ibus-kkc, the candidate list on top of the on-screen keyboard does *not* disappear when committing the candidate currently shown in the preedit by clicking on the Return key. Same with ibus-libpinyin, when committing the candidate currently shown in the preedit by clicking on the space bar on the on-screen keyboard, the candidate list does *not* disappear. Also the same with ibus-typing-booster, when committing the candidate currently shown in the preedit by clicking either on the space bar or the return key on hte on-screen keyboard, the candidate list does *not* disappear. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2015149

2 months, 1 week

1
11
0 / 0

[Bug 2095164] New: Conversion region of ibus-anthy is invisible in konsole, kwrite, kate

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2095164 Bug ID: 2095164 Summary: Conversion region of ibus-anthy is invisible in konsole, kwrite, kate Product: Fedora Version: 36 Status: NEW Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: mfabian(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 Target Milestone: --- Classification: Fedora Created attachment 1888253 --> https://bugzilla.redhat.com/attachment.cgi?id=1888253&action=edit Video showing the the conversion region is visible in some places but invisible in konsole, kwrite, kate Using Fedora-Workstation-Live-x86_64-36-1.2.iso installed in qemu-kvm with all current updates. kwrite, kate, and konsole, do not show the conversion region when using ibus-anthy konsole5-22.04.1-1.fc36.x86_64 kwrite-22.04.1-1.fc36.x86_64 kate-21.12.2-1.fc36.x86_64 It does not matter whether these programs are used in Plasma(X11), Plasma(Wayland), Gnome(Xorg), Gnome(Wayland), the behaviour is always the same, the conversion region is never visible. In konsole the behaviour is even worse because not even the cursor is shown at the start of the conversion region. When testing in Plasma(Wayland) or Plasma(X11) and typing with ibus-anthy into the search field of the KDE control center, the conversion region is coloured and thus visible. It is also visible when typing into the entry field for a command which opens with Alt+F2. So there are only some programs in KDE where it does not work like konsole, kwrite, kate, ... whereas it works in other places. See the attached video. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2095164

3 months, 2 weeks

1
11
0 / 0

[Fedora-i18n-bugs] [Bug 1910836] New: stardict-3.0.6.2 is available

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1910836 Bug ID: 1910836 Summary: stardict-3.0.6.2 is available Product: Fedora Version: rawhide Status: NEW Component: stardict Keywords: FutureFeature, Triaged Assignee: psatpute(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: anish.developer(a)gmail.com, i18n-bugs(a)lists.fedoraproject.org, nav007(a)gmail.com, petersen(a)redhat.com, psatpute(a)redhat.com, pwu(a)redhat.com, robinlee.sysu(a)gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.0.6.2 Current version/release in rawhide: 3.0.6-15.fc33 URL: http://sourceforge.net/projects/stardict-4 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/4887/ -- You are receiving this mail because: You are on the CC list for the bug.

3 months, 2 weeks

1
4
0 / 0

[Fedora-i18n-bugs] [Bug 1813728] New: Square four dot Unicode character has incorrect glyph

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1813728 Bug ID: 1813728 Summary: Square four dot Unicode character has incorrect glyph Product: Fedora Version: 31 Hardware: x86_64 OS: Linux Status: NEW Component: pango Severity: low Assignee: pwu(a)redhat.com Reporter: guillaumepoiriermorency(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: caillon+fedoraproject(a)gmail.com, fonts-bugs(a)lists.fedoraproject.org, gnome-sig(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, john.j5live(a)gmail.com, mclasen(a)redhat.com, pwu(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: The glyph for the Unicode "square four dot" character is incorrect. Version-Release number of selected component (if applicable): I think this problem arose when upgrading from Fedora 30 to Fedora 31. How reproducible: The simplest way is to start GNOME Characters Map and search for "square four dot". -- You are receiving this mail because: You are on the CC list for the bug.

3 months, 3 weeks

1
20
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs July 2022