[Fedora-i18n-bugs] [Bug 851758] New: ibus does not honor the default input method configured in ibus-setup
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=851758
Bug ID: 851758
QA Contact: extras-qa(a)fedoraproject.org
Severity: high
Version: 17
Priority: unspecified
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Assignee: tfujiwar(a)redhat.com
Summary: ibus does not honor the default input method
configured in ibus-setup
Regression: ---
Story Points: ---
Classification: Fedora
OS: Linux
Reporter: pswo10680(a)gmail.com
Type: Bug
Documentation: ---
Hardware: All
Mount Type: ---
Status: NEW
Component: ibus
Product: Fedora
Description of problem:
I am a Chinese (Taiwan) user.
I use ibus-setup to configure the default input method I want to use. I have
selected "English (US)" as the default. However, ibus always give me
ibus-chewing first after I log in GNOME.
Version-Release number of selected component (if applicable):
1.4.99.20120717
How reproducible:
Always
Steps to Reproduce:
1. execute "ibus-setup", switch to "input method" tab.
2. I move English (US) to the top of the list while I am in zh_TW locale.
3. relogin, and you see the input method indicator showing ibus-chewing is
active.
Actual results:
ibus-chewing as default.
Expected results:
The method you set in ibus-setup should be the default one.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years, 10 months
[Fedora-i18n-bugs] [Bug 904117] New: Czech "cs" keymap shipped is uncomplete and has several problems
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=904117
Bug ID: 904117
Summary: Czech "cs" keymap shipped is uncomplete and has
several problems
Product: Fedora
Version: 18
Component: rdesktop
Severity: medium
Priority: unspecified
Reporter: zidek(a)master.cz
+++ This bug was initially created as a clone of Bug #693890 +++
Created attachment 490071
fixed cs keymap by Jaroslav Jiricka
Description of problem:
Czech "cs" keymap shipped in Fedora package is uncomplete and has several
problems which make it unusable, such as remapping the small letter e to Euro
sign. Special characters written using right alt also don't work.
Version-Release number of selected component (if applicable):
rdesktop-1.6.0-10.fc14.x86_64
How reproducible:
Run rdesktop with locale set to cs_CZ.utf8 and connect to czech windows with CS
keyboard set in windows. Now try to type letter "e", Euro sign will appear.
Steps to Reproduce:
1. set locale to czech language cs_CZ.utf8 and keyboard to czech quertz
2. connect to czech windows with CS keyboard set in windows
3. try to type letter "e"
Actual results:
Euro sign will appear
Expected results:
letter e should appear
Additional info:
Problem has been reported upstream
http://sourceforge.net/tracker/index.php?func=detail&aid=1725634&group_id...
attached keymaps cs and additional works ok. Rdesktop rpm should ship with
those files.
--- Additional comment from Martin Zidek on 2011-04-05 16:23:12 EDT ---
Created attachment 490072
additional keymap Jaroslav Jiricka
--- Additional comment from Dušan Hokův on 2011-06-23 07:56:45 EDT ---
Same issue in Fedora 15, described simple patch solved the problem.
--- Additional comment from Akira TAGOH on 2011-12-05 06:06:31 EST ---
Does this still persist in f16 say?
--- Additional comment from Martin Zidek on 2012-01-25 05:29:00 EST ---
Issue still present in f16, tested on f16 rdesktop-1.7.0-1.fc16
--- Additional comment from Ladislav Nesnera on 2012-11-21 16:56:15 EST ---
This problem persists in rdesktop.x86_64 1.7.0-2.fc17 :(
I tried patch above but it doesn't work well for me - czech specific keys are
duplicated - e.g. pressing key 5 (in en-us layout) gives řř not ř. Maybe I used
it by wrong way (I substituted /usr/share/rdesktop/keymaps/cs by this patch)
I found out this version of keymap -
https://www.abclinuxu.cz/poradna/linux/show/181220#10 and I know about only
one problem (AltGr+v should generate @ but do nothing), nevertheless it's much,
much better then current state).
Btw - FreeRDP works well outofbox..
--- Additional comment from Fedora End Of Life on 2013-01-16 12:30:00 EST ---
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--
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=PlrsIFG2xM&a=cc_unsubscribe
10 years, 10 months
[Fedora-i18n-bugs] [Bug 872880] New: [abrt] fcitx-4.2.5-1.fc17: exit: Process /usr/bin/fcitx was killed by signal 11 (SIGSEGV)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=872880
Bug ID: 872880
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Whiteboard: abrt_hash:3c937ea7b7bc5371c979fe703c800dd400a267e9
Version: 17
Priority: unspecified
CC: i18n-bugs(a)lists.fedoraproject.org,
liangsuilong(a)gmail.com, robinlee.sysu(a)gmail.com
Assignee: liangsuilong(a)gmail.com
Summary: [abrt] fcitx-4.2.5-1.fc17: exit: Process
/usr/bin/fcitx was killed by signal 11 (SIGSEGV)
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: xiangjihan(a)gmail.com
Type: ---
Documentation: ---
Hardware: i686
Mount Type: ---
Status: NEW
Component: fcitx
Product: Fedora
Version-Release number of selected component:
fcitx-4.2.5-1.fc17
Additional info:
libreport version: 2.0.16
abrt_version: 2.0.16
backtrace_rating: 4
cmdline: fcitx
crash_function: exit
kernel: 3.6.3-1.fc17.i686.PAE
truncated backtrace:
:Thread no. 1 (10 frames)
: #6 exit at exit.c:100
: #7 OnException at /usr/src/debug/fcitx-4.2.5/src/core/errorhandler.c:106
: #10 error_get_my_stack at error.c:134
: #11 nss_ClearErrorStack at error.c:281
: #12 NSSArena_Create at arena.c:385
: #13 NSSTrustDomain_Create at trustdomain.c:70
: #14 STAN_LoadDefaultNSS3TrustDomain at pki3hack.c:154
: #15 nss_Init at nssinit.c:691
: #16 NSS_NoDB_Init at nssinit.c:909
: #17 rpmInitCrypto at rpmpgp.c:1642
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years, 10 months
[Fedora-i18n-bugs] [Bug 889309] New: [abrt] translate-toolkit-1.9.0-2.fc17: tmdb.py:177:init_fulltext:OperationalError: database schema has changed
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=889309
Bug ID: 889309
Summary: [abrt] translate-toolkit-1.9.0-2.fc17:
tmdb.py:177:init_fulltext:OperationalError: database
schema has changed
Product: Fedora
Version: 17
Component: translate-toolkit
Severity: unspecified
Priority: unspecified
Reporter: cjlhomeaddress(a)gmail.com
Version-Release number of selected component:
translate-toolkit-1.9.0-2.fc17
Additional info:
libreport version: 2.0.18
abrt_version: 2.0.18
cmdline: /usr/bin/python /usr/bin/tmserver -b localhost -p 55555 -d
/home/cjl/.virtaal/tm.db --min-similarity=70 --max-candidates=5
kernel: 3.6.9-2.fc17.i686
backtrace:
:tmdb.py:177:init_fulltext:OperationalError: database schema has changed
:
:Traceback (most recent call last):
: File "/usr/bin/tmserver", line 27, in <module>
: tmserver.main()
: File "/usr/lib/python2.7/site-packages/translate/services/tmserver.py", line
197, in main
: prefix="/tmserver", source_lang=options.source_lang,
target_lang=options.target_lang)
: File "/usr/lib/python2.7/site-packages/translate/services/tmserver.py", line
45, in __init__
: self.tmdb = tmdb.TMDB(tmdbfile, max_candidates, min_similarity,
max_length)
: File "/usr/lib/python2.7/site-packages/translate/storage/tmdb.py", line 68,
in __init__
: self.init_fulltext()
: File "/usr/lib/python2.7/site-packages/translate/storage/tmdb.py", line 177,
in init_fulltext
: self.cursor.executescript(script)
:OperationalError: database schema has changed
:
:Local variables in innermost frame:
:self: <translate.storage.tmdb.TMDB object at 0xb724320c>
:e: OperationalError('database is locked',)
:script: '\nDROP TRIGGER IF EXISTS sources_insert_trig;\nDROP TRIGGER IF EXISTS
sources_update_trig;\nDROP TRIGGER IF EXISTS sources_delete_trig;\n'
--
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=HW1kpDAAn3&a=cc_unsubscribe
10 years, 10 months
[Fedora-i18n-bugs] [Bug 525371] New: [CJK] vertical clock time text rotated wrong way
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: [CJK] vertical clock time text rotated wrong way
https://bugzilla.redhat.com/show_bug.cgi?id=525371
Summary: [CJK] vertical clock time text rotated wrong way
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: gnome-panel
AssignedTo: rstrode(a)redhat.com
ReportedBy: petersen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, rstrode(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Created an attachment (id=362429)
--> (https://bugzilla.redhat.com/attachment.cgi?id=362429)
f12-vert-clock.png
Description of problem:
In F12 the rotation of vertical text seems to have changed.
For Chinese, Japanese and Korean the time is opposite
direction to the date also.
Version-Release number of selected component (if applicable):
How reproducible:
every time
Steps to Reproduce:
1. start CJK gnome desktop
2. create a left panel
3. add clock
Actual results:
see screenshot
Expected results:
closer to f11 would be better
(ideally ideally should be vertical not rotated)
--
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.
10 years, 11 months
[Fedora-i18n-bugs] [Bug 834971] New: ibus-table key input limitation makes it hard to input Traditional Chinese with Quick and Cangjie
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=834971
Bug ID: 834971
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: rawhide
Priority: unspecified
CC: i18n-bugs(a)lists.fedoraproject.org, jni(a)redhat.com,
me(a)kaio.net, shawn.p.huang(a)gmail.com
Assignee: jni(a)redhat.com
Summary: ibus-table key input limitation makes it hard to input
Traditional Chinese with Quick and Cangjie
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: petersen(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: ibus-table
Product: Fedora
This was originally brought up by Mathieu Bridon and other Hong Kong Fedora
users. The text below is adopted from his mail.
Here's a proposal to fix IBus Table for Hong Kong users.
Both Cangjie and Quick can be used to type Simplified and Traditional
Chinese, however, given their design, there isn't any combination of keys that
would conflict between those languages. In other words, any given
combination of character can only lead to results in one of those
languages, never more than one.
Given all that, it would make sense to simply remove altogether the IBus
filter for the Cangjie and Quick input methods in IBus.
Let's take an example.
In Cangjie, the combination "rji" can only return results in Traditional
Chinese. That means if a user types this combination of keys, he is
expecting results in Traditional Chinese because that's the language
he/she wants to type.
But with the current IBus filter, if the filter is set to only let
Simplified Chinese characters pass, he/she would not get any results.
In the same way, the combination "yri" can only return results in
Simplified Chinese, and the combination "fji" can only return results in
Japanese.
[ed: I have never heard of people using ibus-table for Japanese input]
This is by design of those two input methods: they were designed to
avoid conflicts.
As such, the filter just makes no sense for Cangjie and Quick, and it
should be simply removed for those two input methods.
Now, in the above I claimed that Cangjie and Quick were designed to have
absolutely zero conflicts, which was a little exaggeration.
In reality, conflicts happen. However, Cangjie and Quick were really
designed with the goal of minimizing conflicts, and they do it so well
that the actual rate of conflicts is 8.04% [1]. This is such a small
number, and it happens in so rare occasions, that it can just be
ignored.
It is also important to note that if 90% of Hong Kong people [2] use
Cangjie and Quick, many people (but much less than in HK) use them in
Taiwan, and almost no one use them in Mainland China or in Japan.
Out of those three, Hong Kong and Taiwan write Traditional Chinese,
Mainland Chinese write Simplified Chinese, and Japanese obviously write
Japanese. So those two input methods really are used almost exclusively
to write Traditional Chinese, which makes the aforementioned 8.04%
figure completely negligible.
As such, it doesn't change the argument at all: the current IBus filter
should be removed for the Cangjie and Quick input methods.
This is an absolute show-stopper for Hong Kong users at the moment
(well, not me, I can't write Chinese , and the simple act of removing
this filter for those two input methods would basically fix 90% of the
problems for 90% of the Hong Kong people.
Do you think you guys could fix this issue before the release of GNOME
3.6?
Of course, we'd be happy to provide a patch if you agree on the solution
and if you can provide some guidance.
[1] There's a scientific paper published on this, but it's unfortunately
only available in Chinese:
http://zh.wikipedia.org/wiki/倉頡輸入法
[2] Not just Linux users, actual **people**, as this is how everyone
learns to type at school in Hong Kong.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years, 11 months
[Fedora-i18n-bugs] [Bug 627193] New: [Indic] [Mail] [HTML] Underline is printed as Strike for Indic Text
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: [Indic] [Mail] [HTML] Underline is printed as Strike for Indic Text
https://bugzilla.redhat.com/show_bug.cgi?id=627193
Summary: [Indic] [Mail] [HTML] Underline is printed as Strike
for Indic Text
Product: Fedora
Version: 13
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: evolution
AssignedTo: mbarnes(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: i18n-bugs(a)lists.fedoraproject.org
CC: mbarnes(a)redhat.com, mcrha(a)redhat.com,
cooly(a)gnome.eu.org
Classification: Fedora
Target Release: ---
Created attachment 440885
--> https://bugzilla.redhat.com/attachment.cgi?id=440885
Screenshot with problme in Hindi
Description of problem:
While printing a mail (even save as PDF) with Body has Underline Indic text,
printed as Strike. As you increase size of font, Striking line moved toward
middle of Word.
Version-Release number of selected component (if applicable):
evolution-2.30.2-4.fc13.x86_64
gtkhtml3-3.30.2-1.fc13.x86_64
How reproducible:
Everytime
Steps to Reproduce:
1. run evolution
2. New Mail - > HTML format
3. input Indic character (इराक़HINDI के कई शहरों मेंENGNLISH धमाके हुए हैं,
जिनमें 30 लोगों के मारे जाने और अन्य)
4. Select +3, +2, +1 Size
5. Select Underline
6. Print (as PDF or Hard copy)
Actual results:
Indic Characters has problem, while English Characters are ok with underline
Expected results:
Underline should under the characters
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
10 years, 11 months
[Fedora-i18n-bugs] [Bug 830377] New: fcitx-gtk2 package's description is wrong
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=830377
Bug ID: 830377
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: 17
Priority: unspecified
CC: i18n-bugs(a)lists.fedoraproject.org,
liangsuilong(a)gmail.com, robinlee.sysu(a)gmail.com
Assignee: liangsuilong(a)gmail.com
Summary: fcitx-gtk2 package's description is wrong
Regression: ---
Story Points: ---
Classification: Fedora
OS: Linux
Reporter: damage3025(a)gmail.com
Type: Bug
Documentation: ---
Hardware: All
Mount Type: ---
Status: NEW
Component: fcitx
Product: Fedora
$ yum info fcitx-gtk2
Loaded plugins: langpacks, presto, refresh-packagekit
Available Packages
Name : fcitx-gtk2
Arch : i686
Version : 4.2.3
Release : 1.fc17
Size : 18 k
Repo : updates
Summary : FCITX im module for gtk2
URL : http://code.google.com/p/fcitx/
License : GPLv2+
Description : This package contains ibus im module for gtk2.
ibus and fcitx are two different input frameworks.
The description is definitely wrong.
BTW, I cannot find fcitx-gtk2 in pkgdb or bugzilla components.
Why can I see it in PackageKit or yum?
I haven't changed any repository settings.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years, 11 months