i18n-bugs May 2018

i18n-bugs@lists.fedoraproject.org

1 participants
110 discussions

[Fedora-i18n-bugs] [Bug 1565499] New: Ibus emoji dialog closes after selecting one emoji.
by bugzilla＠redhat.com 20 Jul '18

20 Jul '18

https://bugzilla.redhat.com/show_bug.cgi?id=1565499 Bug ID: 1565499 Summary: Ibus emoji dialog closes after selecting one emoji. Product: Fedora Version: 28 Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: poyadav(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 Description of problem: ibus emoji dialog box closes after selecting one emoji only, need to launch it again if we need to select another emoji. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Launch ibus emoji dialog using ibus emoji or ctrl-shift-e. 2. Search for a emoji and select it. 3. After selecting the emoji, dialog box closes Actual results: Dialog box closes after selecting one emoji Expected results: Additional info: Ibus emoji should box should remain open if we haven't closed it, so that we don't have to open it again if we want to select more than one emoji. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Fedora-i18n-bugs] [Bug 1569943] New: upgrading from Liberation 1 to 2 in a desktop session can affect rendering of text
by bugzilla＠redhat.com 19 Jul '18

19 Jul '18

https://bugzilla.redhat.com/show_bug.cgi?id=1569943 Bug ID: 1569943 Summary: upgrading from Liberation 1 to 2 in a desktop session can affect rendering of text Product: Fedora Version: rawhide Component: liberation-fonts Assignee: psatpute(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: alexl(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, john.j5live(a)gmail.com, mbarnes(a)fastmail.com, mclasen(a)redhat.com, petersen(a)redhat.com, psatpute(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com Description of problem: The Liberation 1 and 2 fonts may be binary incompatible in the sense that upgrading a live desktop from Liberation 1 to 2 seemed to corrupt some characters for me in Firefox (with Ariel text in Google Docs for the default unordered list mark symbols). Version-Release number of selected component (if applicable): liberation-fonts-2.00.1 Actual results: '·' -> '>' '⃝' -> '<' for example Expected results: Not change of glyphs. Additional info: I suspect this might be due to caching of the old font's tables in memory. It would be better if the tables were more compatible I suppose. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Fedora-i18n-bugs] [Bug 1382982] New: Fedora iBus typing language detector breaks events call stack of web pages
by Red Hat Bugzilla 19 Jul '18

19 Jul '18

https://bugzilla.redhat.com/show_bug.cgi?id=1382982 Bug ID: 1382982 Summary: Fedora iBus typing language detector breaks events call stack of web pages Product: Fedora Version: 24 Component: ibus Severity: urgent Assignee: tfujiwar(a)redhat.com Reporter: danielemi(a)hotmail.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 Created attachment 1208438 --> https://bugzilla.redhat.com/attachment.cgi?id=1208438&action=edit html page for test purpose Description of problem: My Fedora box is configured with two typing language between which I can switch, English and Chinese. I'm using Firefox v49 as browser. I'm developing a webpage, a registration form using jQuery on the validation part. The registration form contain 4 input controls with 2 password controls, all validated on the blur event. The form script is kind of complex one using blur, and focus events and a list of functions. The form script completely mess up on the live validation of the fields due to the presence of the two password controls on which only latin alphabet is allowed. The ibus language detector change on the fly when the two password fields received focus causing blur and focus events of different contols to happen in unexpected order. It is like ibus is taking the focus and releasing. I tested both jQuery (all the available methods) and pure javascript with the same result. I had the chance to try other websites using blur and focus events on password fields and are completely mess up too. To finish my job I will unset the Chinese IME. I can't guess what is about application development in the same context. Version-Release number of selected component (if applicable): Fedora 24 4.7.5-200.fc24.x86_64 ibus-1.5.13-3.fc24.x86_64 How reproducible: https://jsfiddle.net/8tqwL7y5 Steps to Reproduce: 1. Settings, Region and Lanaguges, input sources: set English (US) and Chinese (intelligent Pinyin) 2. try the link 3. try the webpage attached Actual results: Blur event doesn't happen or happen just mixed up with other events like other control's Focus events. Expected results: Blur and Focus events get fired in common order on the events call stack -- You are receiving this mail because: You are on the CC list for the bug.

2 18

[Fedora-i18n-bugs] [Bug 1296121] New: XIM: When commiting with a space, it is inserted before a hangul character rather than after it
by Red Hat Bugzilla 11 Jul '18

11 Jul '18

https://bugzilla.redhat.com/show_bug.cgi?id=1296121 Bug ID: 1296121 Summary: XIM: When commiting with a space, it is inserted before a hangul character rather than after it Product: Fedora Version: 23 Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: psabata(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 Description of problem: This appears to be a recurring issue; I recall this was fixed a few times already :) The behavior is similar to #675503. However, only XIM appears to be affected this time; the input works fine in a GTK+v2 application. Version-Release number of selected component (if applicable): ibus-1.5.11-1.fc23.x86_64 ibus-libs-1.5.11-1.fc23.x86_64 ibus-hangul-1.5.0-5.fc23.x86_64 ibus-gtk2-1.5.11-1.fc23.x86_64 How reproducible: Always with XIM. Never with GTK+v2. Steps to Reproduce: 1. Run ibus with XIM ibus-daemon -x 2. Set your environment and run something that uses it, e.g. xterm -- export XMODIFIERS='@im=ibus' xterm 3. Type some hangul and commit with a space, e.g. "하나 둘 셋" (input being "gksk enf tpt ") Actual results: "하 나 둘 셋" Expected results: "하나 둘 셋 " Additional info: -- 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=cxyVQxcKBJ&a=cc_unsubscribe

2 17

[Fedora-i18n-bugs] [Bug 1398181] New: Start at hangul does not work
by Red Hat Bugzilla 03 Jul '18

03 Jul '18

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.

2 11

[Fedora-i18n-bugs] [Bug 1040336] New: [or_IN][libuninum] - Change language name from "Oriya" to "Odia"
by Red Hat Bugzilla 29 Jun '18

29 Jun '18

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-s… 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

2 13

[Fedora-i18n-bugs] [Bug 1564349] New: Typing Booster should use a single unified IME ( Input Source) for all languages
by bugzilla＠redhat.com 28 Jun '18

28 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1564349 Bug ID: 1564349 Summary: Typing Booster should use a single unified IME (Input Source) for all languages Product: Fedora Version: 28 Component: ibus-typing-booster Severity: high Assignee: mfabian(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: anish.developer(a)gmail.com, i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com Description of problem: Currently ibus-typing-booster provides one IME per locale which creates many many input sources which seems not so good. Version-Release number of selected component (if applicable): ibus-typing-booster-1.5.35-1 Additional info: Only downside I see is that Typing Booster will not be listed under every language in gnome-control-center or ibus-setup... On the plus side an IME called Typing Booster will be much more differentiated in the IME switcher or Input Source menu, strengthening the aware of the project. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Fedora-i18n-bugs] [Bug 1577820] New: iso-codes-3.79 is available
by bugzilla＠redhat.com 26 Jun '18

26 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1577820 Bug ID: 1577820 Summary: iso-codes-3.79 is available Product: Fedora Version: rawhide Component: iso-codes Keywords: FutureFeature, Triaged Assignee: pnemade(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: alexl(a)redhat.com, caillon+fedoraproject(a)gmail.com, i18n-bugs(a)lists.fedoraproject.org, john.j5live(a)gmail.com, mbarnes(a)fastmail.com, mclasen(a)redhat.com, pnemade(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com Latest upstream release: 3.79 Current version/release in rawhide: 3.77-2.fc28 URL: http://pkg-isocodes.alioth.debian.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/1406/ -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Fedora-i18n-bugs] [Bug 1582935] New: mozc: FTBFS in Fedora 28
by bugzilla＠redhat.com 12 Jun '18

12 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1582935 Bug ID: 1582935 Summary: mozc: FTBFS in Fedora 28 Product: Fedora Version: 28 Component: mozc Assignee: tagoh(a)redhat.com Reporter: releng(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, robinlee.sysu(a)gmail.com, tagoh(a)redhat.com, tfujiwar(a)redhat.com Blocks: 1555378 mozc failed to build from source in Fedora 28 https://koji.fedoraproject.org/koji/taskinfo?taskID=27212199 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild Please fix mozc at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, mozc will be orphaned. Before branching of Fedora 29, mozc will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1555378 [Bug 1555378] (F28FTBFS) Fedora 28 Mass Rebuild FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Fedora-i18n-bugs] [Bug 1133127] New: The hotkey for switching to direct input mode should be configurable
by Red Hat Bugzilla 12 Jun '18

12 Jun '18

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

2 111

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs May 2018