April 2022 - i18n-bugs - Fedora Mailing-Lists

[Bug 2074360] New: Xorg gtk4: candidate windows are placed off-screen

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2074360 Bug ID: 2074360 Summary: Xorg gtk4: candidate windows are placed off-screen Product: Fedora Version: 36 Status: NEW Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: petersen(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 Description of problem: With Gnome on Xorg using gtk4 apps, the candidate is often placed partially or completely off-screen, which is not useful of course. Version-Release number of selected component (if applicable): ibus-1.5.26-3.fc36.x86_64 gtk4-4.6.2-2.fc36.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start GNOME on Xorg 2. Open gnome-text-editor or gtk4-demo-application 3. Try to input Japanese or Chinese Actual results: Candidate window is place off-window or off-screen Expected results: Candidate window to be visible like with gtk3 apps Additional info: Is there some way to enforce that candidate windows should always appear on-screen? -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2074360

5 months, 4 weeks

1
7
0 / 0

[Bug 2004265] New: Official name of Taiwan is wrong

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2004265 Bug ID: 2004265 Summary: Official name of Taiwan is wrong Product: Fedora Version: 35 Hardware: All Status: NEW Component: iso-codes Assignee: pnemade(a)redhat.com Reporter: julian.g(a)posteo.de QA Contact: extras-qa(a)fedoraproject.org CC: caillon+fedoraproject(a)gmail.com, 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 Target Milestone: --- Classification: Fedora Description of problem: The "official name" of the country on Taiwan is wrong. It states "Province of China", which is obviously not its official name. No country would call itself "Province" of another country. The official name is "Republic of China". Some sources: - Official government website https://www.taiwan.gov.tw by the RoC Ministry of Foreign Affairs - You can ask any person living on the Island. - As an IT person, you might have some hardware labeled "Made in RoC". - The Hong Kong and the Taiwanese locale both have "中華民國" as a translation, which means "Republic of China". -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2004265

6 months, 1 week

1
31
0 / 0

[Fedora-i18n-bugs] [Bug 1919963] New: /usr/share/doc/libunistring-devel/libunistring.html missing in devel

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1919963 Bug ID: 1919963 Summary: /usr/share/doc/libunistring-devel/libunistring.html missing in devel Product: Fedora Version: 32 Hardware: All OS: All Status: NEW Component: libunistring Severity: medium Assignee: p(a)draigbrady.com Reporter: reini.urban(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, jim(a)meyering.net, p(a)draigbrady.com, redhat-bugzilla(a)linuxnetz.de Target Milestone: --- Classification: Fedora Description of problem: after installing libunistring and libunistring-devel the main doc entrypoint for html is missing. /usr/share/doc/libunistring-devel/libunistring.html Version-Release number of selected component (if applicable): libunistring-devel-0.9.10-7.fc32.x86_64 How reproducible: Open a html doc, and click on Contents. e.g firefox /usr/share/doc/libunistring-devel/libunistring_1.html Haven't checked if that is an upstream problem, or just a bad rpm spec. -- You are receiving this mail because: You are on the CC list for the bug.

6 months, 1 week

1
8
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

6 months, 1 week

1
6
0 / 0

[Bug 2013610] New: Problem when ibus uses XIM: When committing something and then sending a space by returning False, the commit and the space are reversed

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2013610 Bug ID: 2013610 Summary: Problem when ibus uses XIM: When committing something and then sending a space by returning False, the commit and the space are reversed 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 1832549 --> https://bugzilla.redhat.com/attachment.cgi?id=1832549&action=edit Video showing the problem using ibus-m17n with si-wijesekera [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 ibus-m17n ibus-m17n-1.4.7-1.fc35.x86_64 [mfabian@fedora ~]$ rpm -q ibus-typing-booster ibus-typing-booster-2.14.13-1.fc35.noarch [mfabian@fedora ~]$ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2013610

6 months, 1 week

1
11
0 / 0

[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

8 months, 3 weeks

1
9
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.

10 months

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

10 months

1
6
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

10 months, 3 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.

12 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs April 2022