July 2017 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 1398181] New: Start at hangul does not work

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1398181 Bug ID: 1398181 Summary: Start at hangul does not work Product: Fedora Version: 25 Component: ibus Severity: medium Assignee: tfujiwar(a)redhat.com Reporter: hwhwang7(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, smaitra(a)redhat.com, tfujiwar(a)redhat.com Description of problem: After the input source 'hangul', I can enable the option 'start at hangul mode'. Even after I enabled it, whenever I switch to hangul, it does not start at hangul mode. Version-Release number of selected component (if applicable): IBus 1.5.14 How reproducible: Always Steps to Reproduce: 1. Add the input source 'hangul' 2. Enable the option 'start at hangul mode'. 3. Switch input mode Actual results: Hangul mode does not start as enabled Expected results: Hangul mode starts as enabled -- You are receiving this mail because: You are on the CC list for the bug.

5 years, 9 months

2
11
0 / 0

[Fedora-i18n-bugs] [Bug 1040336] New: [or_IN][libuninum] - Change language name from "Oriya" to "Odia"

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1040336 Bug ID: 1040336 Summary: [or_IN][libuninum] - Change language name from "Oriya" to "Odia" Product: Fedora Version: rawhide Component: libuninum Keywords: i18n Severity: low Priority: medium Assignee: terjeros(a)phys.ntnu.no Reporter: smaitra(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, smaitra(a)redhat.com, terjeros(a)phys.ntnu.no Description of problem: Upstream bug reference : https://sourceware.org/bugzilla/show_bug.cgi?id=15601 Preface : As per the Govt of India record, the State name of Orissa has been replaced with Odisha (hopefully I am correct with its spelling) and the language of Odisha State which was Oriya earlier, has been replaced with Odia. Please change the word "Oriya" occurrences to "Odia" in SPEC file. Version-Release number of selected component (if applicable): libuninum-2.7-13.fc20.1 libuninum-2.7-13.fc20.1 How reproducible: N/A Steps to Reproduce:N/A 1. 2. 3. Actual results: Presently the word "Oriya" is mentioned in the SPEC file. Expected results: Please replace the word "Oriya" with the word "Odia" in the SPEC File for all the occurrences. Additional info: References: http://orissamatters.com/2011/11/07/orissa-became-odisha/ http://www.ndtv.com/article/india/parliament-passes-bill-to-change-orissa... http://orissa.gov.in/e-magazine/Orissareview/2011/Nov/engpdf/9-17.pdf -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YHitKy2naE&a=cc_unsubscribe

5 years, 9 months

2
13
0 / 0

[Fedora-i18n-bugs] [Bug 1133127] New: The hotkey for switching to direct input mode should be configurable

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1133127 Bug ID: 1133127 Summary: The hotkey for switching to direct input mode should be configurable Product: Fedora Version: 19 Component: ibus-table Assignee: mfabian(a)redhat.com Reporter: stsp(a)list.ru QA Contact: extras-qa(a)fedoraproject.org CC: dchen(a)redhat.com, extras-qa(a)fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, kent.neo(a)gmail.com, me(a)kaio.net, mfabian(a)redhat.com, pwu(a)redhat.com, shawn.p.huang(a)gmail.com, stsp(a)list.ru +++ This bug was initially created as a clone of Bug #1128912 +++ (In reply to Stas Sergeev from comment #23) > I noticed another problem. > When I type, the layout ocasionally changes back > to EN, even though I do not press the modifier combo. > The switcher applet still shows RU, but the typing > becomes latinic. > Presumably this happens after Shift-Space, but again, > not always... So we have another puzzle. I wonder if > you can make a sharp guess or reproduce that... You are switching between table mode ("rusle") and direct input mode (using the underlying keyboard layout directly). The hotkey for this is the left shift key (Without space, just left shift and release it). You can see which mode you are in if you open the input method menu in the gnome panel while rusle is active. Look at the 4 menu entries near the bottom: Direct input (Left Shift) Phrase mode (Ctrl-;) <- quite useless for rusle Direct commit mode (Ctrl-/) <- quite useless for rusle Setup If you hit the left shift key and look again, you see that the topmost of these "property" menus toggles between Direct input (Left Shift) <-> Р (Left Shift) I am not sure what I can do about this now. For Chinese, this is used often as a quick way to toggle between Chinese and English mode (faster than switching between two input sources). That might be the reason why the original developer of ibus-table did choose the left shift key as the hot key for that. The disadvantage is of course that the left shift key can be hit far too easily. In the long run, I want to make the keybindings configurable, then you could set that keybinding to empty. But I have no time for that soon, that is a bit more work. Choosing a different shortcut is not nice to existing users. Disabling that shortcut for non-CJK input methods might also be not so nice. Maybe one wants to quickly toggle between direct input and a non-CJK input method as well. So I am a bit puzzled what to do about this now. Maybe wait until I have time to make the keybindings configurable? --- Additional comment from Stas Sergeev on 2014-08-22 15:32:52 EDT --- > Maybe wait until I have time to make the keybindings configurable? Maybe I have no other option than to agree with this? :) Anyway, another sharp guess, you are right, left shift is the culprit. Thank you. So, should I open a separate report for this or what? --- Additional comment from Stas Sergeev on 2014-08-22 15:34:22 EDT --- (In reply to Mike FABIAN from comment #24) > Created attachment 929759 [details] > 0001-Ignore-Shift-Space-hotkey-to-switch-fullwidth-halfwi.patch > > To fix the problem in comment#21 Patch tested and works. --- Additional comment from Mike FABIAN on 2014-08-22 15:55:18 EDT --- (In reply to Stas Sergeev from comment #26) > > Maybe wait until I have time to make the keybindings configurable? > Maybe I have no other option than to agree with this? :) > Anyway, another sharp guess, you are right, left shift > is the culprit. Thank you. > > So, should I open a separate report for this or what? Yes, I think a separate bug report is helpful so I do not forget this. Maybe, as a temporary workaround, I disable that hotkey for non-CJK and enable it again as soon as the hotkeys are configurable. I really should make the hotkeys configurable ... -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DFaAYcdVbL&a=cc_unsubscribe

5 years, 10 months

2
111
0 / 0

[Fedora-i18n-bugs] [Bug 1368757] New: ibus: forward_key_event() seems to do nothing in Qt applications

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1368757 Bug ID: 1368757 Summary: ibus: forward_key_event() seems to do nothing in Qt applications Product: Fedora Version: 24 Component: ibus-qt 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 If I try to type with ibus-typing-booster in Qt applications and commit a word by typing space, no space is inserted after the word. For example: QT_IM_MODULE=ibus kate & Select the English engine of ibus-typing-booster and type some word like "test", type space to commit. The word "test" is committed into kate, but no space appears after the word, the cursor is directly behind the word "test". This is because this line self.forward_key_event(key.val, key.code, key.state) in hunspell_table.py from ibus-typing-booster does nothing anymore. This line in context in the source code is here: https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hun... (By the way, when trying “XMODIFIERS=@im=ibus QT_IM_MODULE=xim kate”, input does not work at all, so this cannot be used as a workaround). -- You are receiving this mail because: You are on the CC list for the bug.

5 years, 10 months

2
12
0 / 0

[Fedora-i18n-bugs] [Bug 1321551] New: RFE: Recommend some specific general purpose font

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1321551 Bug ID: 1321551 Summary: RFE: Recommend some specific general purpose font Product: Fedora Version: rawhide Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: ville.skytta(a)iki.fi QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com, tagoh(a)redhat.com Currently fontconfig has a dependency on font(:lang=en). For minimal setups where fontconfig is involved in that don't specify anything more specific than that, it results in getting the first satisfying package by alphabetical sort order to be installed. At the moment that is aajohan-comfortaa-fonts, which is not a very good default, and could change based on what names of packages are available. Instead, I suggest adding (in addition to the existing hard dependency on font(:lang=en)) a Recommends that would by default (with dnf) pull in something that is a better default and already a default in common Fedora installations, such as abattis-cantarell-fonts which AFAIK is the default for GNOME. Some other potential candidates would be liberation-sans-fonts and dejavu-sans-fonts. Not sure if Suggests would work for this purpose, or if it needs to be Recommends. -- You are receiving this mail because: You are on the CC list for the bug.

5 years, 10 months

2
2
0 / 0

[Fedora-i18n-bugs] [Bug 1474422] New: [abrt] ibus: ffi_call_unix64(): ibus-x11 killed by signal 11

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1474422 Bug ID: 1474422 Summary: [abrt] ibus: ffi_call_unix64(): ibus-x11 killed by signal 11 Product: Fedora Version: 26 Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: wd(a)denx.de QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, smaitra(a)redhat.com, tfujiwar(a)redhat.com Description of problem: Fresh install of Fedora 26. Then installed the FVWMpackage. Rebootet and tried to log in using "fvwm" as window manager option. Zero other activities. Version-Release number of selected component: ibus-1.5.16-2.fc26 Additional info: reporter: libreport-2.9.1 backtrace_rating: 4 cmdline: /usr/libexec/ibus-x11 --kill-daemon crash_function: ffi_call_unix64 executable: /usr/libexec/ibus-x11 journald_cursor: s=081922fbe12a436c99bf0ca7fce84f90;i=13f6;b=e2981484247f4c3ebebbefed1ee8bb6e;m=11dc8ca3;t=5551155385856;x=d48075e2c4636bb3 kernel: 4.11.8-300.fc26.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 -- You are receiving this mail because: You are on the CC list for the bug.

5 years, 10 months

1
6
0 / 0

[Fedora-i18n-bugs] [Bug 1444357] New: [abrt] ibus: gtk_widget_translate_coordinates(): ibus-ui-emojier killed by signal 11

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1444357 Bug ID: 1444357 Summary: [abrt] ibus: gtk_widget_translate_coordinates(): ibus-ui-emojier killed by signal 11 Product: Fedora Version: 26 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, smaitra(a)redhat.com, tfujiwar(a)redhat.com Version-Release number of selected component: ibus-1.5.15-7.fc26 Additional info: reporter: libreport-2.9.1 backtrace_rating: 4 cmdline: /usr/libexec/ibus-ui-emojier crash_function: gtk_widget_translate_coordinates executable: /usr/libexec/ibus-ui-emojier journald_cursor: s=664b04056b90495eb16b01faf8679d24;i=50ac;b=49987fadbf444363972d43c8efe305d9;m=8c993bfce1;t=54c68c07c4671;x=2b461df22db5e7cb kernel: 4.11.0-0.rc3.git0.2.fc26.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 gtk_widget_translate_coordinates at gtkwidget.c:6292 #1 _update_widget_coordinates at gtkgesture.c:504 #2 _gtk_gesture_update_point at gtkgesture.c:611 #3 gtk_gesture_handle_event at gtkgesture.c:740 #4 gtk_gesture_single_handle_event at gtkgesturesingle.c:222 #5 gtk_event_controller_handle_event at gtkeventcontroller.c:230 #6 controller_handle_wm_event at gtkwindow.c:8071 #7 gtk_window_handle_wm_event at gtkwindow.c:8100 #8 _gtk_window_check_handle_wm_event at gtkwindow.c:8138 #9 gtk_main_do_event at gtkmain.c:1748 -- You are receiving this mail because: You are on the CC list for the bug.

5 years, 10 months

1
4
0 / 0

[Fedora-i18n-bugs] [Bug 657849] New: Serbian glyphs for Wikipedia

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: Serbian glyphs for Wikipedia https://bugzilla.redhat.com/show_bug.cgi?id=657849 Summary: Serbian glyphs for Wikipedia Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: liberation-fonts AssignedTo: psatpute(a)redhat.com ReportedBy: alessandroceschini.it(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Description of problem: Hy, at the Serbian Wikipedia we are planning on supporting localized Serbian glyphs (as opposed to standard/Russian ones) on screen by taking advantage of the next generation of browser (like Firefox 4) compliant with OpenType features. What we lack is a pool of free OpenType fonts with Serbian glyphs to be accessed through the locl feature. DejaVu is, as far as I know, the only free font which does so (although with some bugs) but, particularly the Serif version, can be described as ugly at best. So, what about a new release of Liberation Fonts containing a locl table for Serbian? Thank you. -- 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.

5 years, 11 months

2
113
0 / 0

[Fedora-i18n-bugs] [Bug 1474257] New: fc-cache in multilib does not create 32bit cache files

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1474257 Bug ID: 1474257 Summary: fc-cache in multilib does not create 32bit cache files Product: Fedora Version: rawhide Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: tagoh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com, tagoh(a)redhat.com Blocks: 1468978 Description of problem: On 64bit env, there are no way to generate {be,le}32d{4,8} caches unless removing 64bit version of packages because the 32bit version of fc-cache binary is hidden by the package manager. need to have separate binary to address like gtk does. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1468978 [Bug 1468978] fc-cache in multilib does not create 32bit cache files -- You are receiving this mail because: You are on the CC list for the bug.

6 years

1
2
0 / 0

[Fedora-i18n-bugs] [Bug 1450802] New: @sinhala-suppport group: please change the default font from LKLUG to Noto

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1450802 Bug ID: 1450802 Summary: @sinhala-suppport group: please change the default font from LKLUG to Noto Product: Fedora Version: 25 Component: google-noto-fonts Severity: low Assignee: psatpute(a)redhat.com Reporter: harshula(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com, pwu(a)redhat.com [This BZ should be filed against the @sinhala-support group.] Description of problem: Please change the default font from LKLUG to Noto for the Sinhala script. The LKLUG font is viewed as deprecated and we've been trying to encourage other fonts that can succeed as the default Sinhala font on GNU/Linux. At this stage the Noto Sinhala range, in fonts-noto-hinted, is a more appropriate default font than LKLUG. See the discussion here: http://sourceforge.net/p/sinhala/mailman/message/34481529/ See Debian Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837969 Thanks, # -- You are receiving this mail because: You are on the CC list for the bug.

6 years

1
18
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs July 2017