[Fedora-i18n-bugs] [Bug 510176] New: unable to display Japanese manpages
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: unable to display Japanese manpages
https://bugzilla.redhat.com/show_bug.cgi?id=510176
Summary: unable to display Japanese manpages
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n, Reopened
Severity: medium
Priority: medium
Component: yelp
AssignedTo: mbarnes(a)redhat.com
ReportedBy: petersen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: mbarnes(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Blocks: 220122
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Clone Of: 220122
+++ This bug was initially created as a clone of Bug #220122 +++
Description of problem:
Try to view man-pages-ja from yelp, however, the contents are not able to be
displayed properly.
How reproducible:
Always
Steps to Reproduce:
1.login desktop with ja_JP locales
2.in yelp, search for info:man
3.
Actual results:
pls refer to screenshot
Expected results:
should display or fallback to english
Additional info:
--- Additional comment from llim(a)redhat.com on 2006-12-18 18:36:20 EDT ---
Created an attachment (id=143967)
--> (https://bugzilla.redhat.com/attachment.cgi?id=143967)
screenshot of yelp displaying man-pages-ja
--- Additional comment from tagoh(a)redhat.com on 2006-12-19 01:01:20 EDT ---
(In reply to comment #3)
> Actually, after looking at the screenshot carefully, seem even in g-t, some of
> the contents are display as "?"
I suppose it's because vte may does wrong thing on Japanese hyphenation or
whatever. it's a different problem anyway.
--
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.
11 years, 6 months
[Fedora-i18n-bugs] [Bug 509478] New: support IME hotkey
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: support IME hotkey
https://bugzilla.redhat.com/show_bug.cgi?id=509478
Summary: support IME hotkey
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: FutureFeature, i18n
Severity: medium
Priority: low
Component: ibus
AssignedTo: phuang(a)redhat.com
ReportedBy: petersen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: wtogami(a)redhat.com, phuang(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Description of problem:
ibus should really support IME-based trigger hotkeys like Windows.
Steps to Reproduce:
1. Run ibus in F11
2. ibus-setup -> hotkeys
Actual results:
Too many hotkeys defined for all for CIJK
Expected results:
Only hotkeys for IMEs in use to be available.
Eg Japanese user should only have Alt-` and Hankaku_Zenkaku
defined by default, not other keys like Ctrl-Space and
Korean hotkeys, etc.
Additional info:
With this change we could also drop defining a global
hotkey by default which would be ibus more acceptable
as a desktop default in the longer term.
--
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.
11 years, 9 months
[Fedora-i18n-bugs] [Bug 517633] New: [ne_NP] icons for rom and trad are exactly same, better it can make difference between two
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: [ne_NP] icons for rom and trad are exactly same, better it can make difference between two
https://bugzilla.redhat.com/show_bug.cgi?id=517633
Summary: [ne_NP] icons for rom and trad are exactly same,
better it can make difference between two
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: m17n-contrib
AssignedTo: pnemade(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: pnemade(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Description of problem:
While using Nepali Desktop, Ibus having same icon for two different available
keyboard layout for Nepali (rom and trad), Which make confusion, which one
currently used. ideal case, if as use, I activate ibus for Nepali, I don't know
which keyboard is currently working (as only icon appearing), only Tool-tip is
showing name
Version-Release number of selected component (if applicable):
m17n-contrib-nepali-1.1.10-1.fc12
How reproducible:
100%
Steps to Reproduce:
1. Add language support for Nepali (yum groupinstall nepali-support)
2. select keyboard layout for Nepali with ibus
3. try to select both different layout (trad/rom), see the icon
Actual results:
Same icon for both keyboard layout
Expected results:
Different (even if very small) icons are more helpful than same.
Additional info:
--
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.
11 years, 11 months
[Fedora-i18n-bugs] [Bug 497095] New: [bn][bn-IN] Incorrect rendering of a consonant conjunct while writing Bengali in KDE Applications
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: [bn][bn-IN] Incorrect rendering of a consonant conjunct while writing Bengali in KDE Applications
https://bugzilla.redhat.com/show_bug.cgi?id=497095
Summary: [bn][bn-IN] Incorrect rendering of a consonant
conjunct while writing Bengali in KDE Applications
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: kde-l10n
AssignedTo: than(a)redhat.com
ReportedBy: runab(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: rdieter(a)math.unl.edu, than(a)redhat.com,
kevin(a)tigcc.ticalc.org, ltinkl(a)redhat.com,
fedora-i18n-bugs(a)redhat.com, smparrish(a)gmail.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Description of problem:
While typing in Bengali within various KDE applications like kwrite, kate,
konqueror etc. the following consonant conjunct is not being rendered
correctly:
র+ZWJ+্+য
The corresponding unicode values for the above are:
U09B0+U200D+U09CD+U09AF
Version-Release number of selected component (if applicable):
KDE 4.2.2.
How reproducible:
Steps to Reproduce:
1. Open kwrite
2. Enter the above consonant conjuct combination using a Bengali keyboard or
Unicode RAWCODE
Actual results:
The consonant is rendered incorrectly.
Screenshot: http://runab.fedorapeople.org/assorted-bugs/incorrect-ra.png
Expected results:
The consonant should be rendered correctly.
Screenshot: http://runab.fedorapeople.org/assorted-bugs/correct-ra.png
Additional info:
This bug exists in earlier versions of Fedora (9, 10) as well
--
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.
12 years, 3 months
[Fedora-i18n-bugs] [Bug 477583] New: add Alt, Esc, Fn, etc to iok
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: add Alt, Esc, Fn, etc to iok
https://bugzilla.redhat.com/show_bug.cgi?id=477583
Summary: add Alt, Esc, Fn, etc to iok
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: iok
AssignedTo: pnemade(a)redhat.com
ReportedBy: petersen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: pnemade(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Description of problem:
iok is currently missing Alt, Esc and Fn function keys: feel it would be good
to add them. It could also be configurable if some people feel that not all
users need them in India.
--
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.
12 years, 5 months
[Fedora-i18n-bugs] [Bug 517635] New: [ne_NP] fc-match showing "Lohit Hindi" instead of current Language
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: [ne_NP] fc-match showing "Lohit Hindi" instead of current Language
https://bugzilla.redhat.com/show_bug.cgi?id=517635
Summary: [ne_NP] fc-match showing "Lohit Hindi" instead of
current Language
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: lohit-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, pnemade(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
psatpute(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Description of problem:
in Nepali Envirnment (gnome-desktop), fc-match is showing following informating
---
$echo $LANG
ne_NP.UTF-8
$fc-match
lohit_hi.ttf: "Lohit Hindi" "Regular"
---
Version-Release number of selected component (if applicable):
lohit-nepali-fonts-2.4.0-2.fc12
How reproducible:
100%
Steps to Reproduce:
1. login to Gnome-desktop with Nepali Language
2. open gnome-terminal
3. type 'fc-match'
Actual results:
lohit_hi.ttf: "Lohit Hindi" "Regular"
Expected results:
lohit_ne.ttf: "Lohit Nepali" "Regular" or something for Nepali
Additional info:
I have file /usr/share/fonts/lohit/lohit_ne.tff on system
--
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.
12 years, 6 months
[Fedora-i18n-bugs] [Bug 518161] New: "contains" expression seems not working on the fontconfig rule
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: "contains" expression seems not working on the fontconfig rule
https://bugzilla.redhat.com/show_bug.cgi?id=518161
Summary: "contains" expression seems not working on the
fontconfig rule
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: tagoh(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, pnemade(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Created an attachment (id=357904)
--> (https://bugzilla.redhat.com/attachment.cgi?id=357904)
sample fontconfig rule
Description of problem:
Even if the pattern contains strings that the rule specifies with "contains"
expression, it doesn't match.
Version-Release number of selected component (if applicable):
fontconfig-2.7.1-1.fc12
How reproducible:
always
Steps to Reproduce:
1.install lohit-hindi-fonts and lohit-marathi-fonts
2.put the attached rule into /etc/fonts/conf.d
3.fc-match "sans-serif:lang=mr"
4.fc-match "sans-serif:lang=mr-in"
Actual results:
3. lohit_mr.ttf: "Lohit Marathi" "Regular"
4. lohit_hi.ttf: "Lohit Hindi" "Regular"
Expected results:
the result of 3 and 4 should be:
lohit_mr.ttf: "Lohit Marathi" "Regular"
Additional info:
>From a debug log:
FcConfigSubstitute test pattern any lang Contains "mr"
FcLangSet mr-in contains mr
Missing bitmap ku-am
No match
I'm not really sure why fontconfig refers ku-am map here but apparently it
looks like fontconfig doesn't know what mr-in is.
Anyway, if no explicit lang pattern is given and applications calls
FcDefaultSubstitute(), lang will be set like mr-in from current locale
mr_IN.UTF-8 say.
--
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.
12 years, 6 months
[Fedora-i18n-bugs] [Bug 487581] New: Liberation Mono: incorrect spacing for Combining Diacritical Marks.
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: Liberation Mono: incorrect spacing for Combining Diacritical Marks.
https://bugzilla.redhat.com/show_bug.cgi?id=487581
Summary: Liberation Mono: incorrect spacing for Combining
Diacritical Marks.
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: liberation-fonts
AssignedTo: cchance(a)redhat.com
ReportedBy: adam.buchbinder(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: cchance(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6)
Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
According to the bug on freedesktop.org (link below), Liberation Mono has an
incorrect spacing definition for "Combining Diacritical Marks"; they should
have zero space, and should render above the last letter, not the next one.
Paste following text with selected font:
Correct: accent above o
Incorrect: accent above g
Reproducible: Always
Steps to Reproduce:
1. Enter a string with a combining diacritic mark in Liberation Mono, e.g.,
"o̍g". Don't use gnome-terminal; it relies on vte, which doesn't handle
combining characters. Use something like gedit; switching fonts will reveal the
issue as the diacritical mark switches places.
Actual Results:
The diacritic appears one letter to the right of where it should be.
Expected Results:
The diacritic should appear in the proper place.
I'm using ttf-liberation 1.04.93-1 on Ubuntu Intrepid; I'm filing this as an
upstream bug. If this should be filed elsewhere, please let me know.
I'm filing this because several monospace fonts have incorrect spacing for
"Combining Diacritical Marks":
http://bugs.freedesktop.org/show_bug.cgi?id=20330
--
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.
12 years, 7 months
[Fedora-i18n-bugs] [Bug 500731] New: Switching on/off behaves weird when compositing enabled
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: Switching on/off behaves weird when compositing enabled
https://bugzilla.redhat.com/show_bug.cgi?id=500731
Summary: Switching on/off behaves weird when compositing
enabled
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: ibus
AssignedTo: phuang(a)redhat.com
ReportedBy: martin.sourada(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: phuang(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Description of problem:
Turning ibus on or off does frequently makes the tool window either
semitransparently reapear after switching to another window (and is not
clickable/working) or not appear (save for its shadow and it is
clickable/working). I can seem to trigger this only when I have compositing in
metacity enabled. Tried chewing and anthy inputs, both suffer from this.
Version-Release number of selected component (if applicable):
ibus-1.1.0.20090508-1.fc11.i586
How reproducible:
seems to be always reproducible sans some applications (e.g. when switching to
ibus settings window, it seems to behave correctly)
Steps to Reproduce:
1. turn on metacity compositing
(gconf->apps->metacity->general->compositin_manager)
2. open two gtk applications that take input from keyboard (e.g. two
gnome-terminals)
3. switch to and fro between those two applications while randomly turning ibus
on and off
Actual results:
Usually after turning it off and switching to other window, the toolbox
reappear (but is semitransparent and not clickable/working), switching back,
turning on and off again and switching again to the other window seems to work
as expeced. Switch back to the first window and turn it on again, usually blank
(fully transparent) toolbox appears. Turning off and on again fix it (or
switching again to and fro between the two applications without explicitly
turning it on/off).
Expected results:
Turns on and off without the strange side effects.
Additional info:
It seems impossible to make a screenshot of the not-appearing one, hitting
print screen makes it reappear. Screenshot of the "false positive" is at
https://www.redhat.com/archives/fedora-test-list/2009-May/png1jbZyCgtB3.png
--
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.
12 years, 9 months
[Fedora-i18n-bugs] [Bug 494902] New: [te_IN] Incorrect glyph substitution for telugu letter ka followed by dep vowel AA then consonant sha and then viram
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: [te_IN] Incorrect glyph substitution for telugu letter ka followed by dep vowel AA then consonant sha and then viram
https://bugzilla.redhat.com/show_bug.cgi?id=494902
Summary: [te_IN] Incorrect glyph substitution for telugu
letter ka followed by dep vowel AA then consonant sha
and then viram
Product: Fedora
Version: 10
Platform: All
OS/Version: Linux
Status: NEW
Severity: high
Priority: low
Component: lohit-fonts
AssignedTo: rbhalera(a)redhat.com
ReportedBy: arjunaraoc(a)googlemail.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, rbhalera(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Clone Of: 494158
+++ This bug was initially created as a clone of Bug #494158 +++
Description of problem:
Incorrect glyph substitution for telugu letter ka followed by dep vowel AA
then consonant sha and then viram
Version-Release number of selected component (if applicable):
2.3.8
How reproducible:
Always
Steps to Reproduce:
1. Type the letters for కా ష్ with out the space between them in gedit
(u+0c15,u+0c3E,u+0c37,u+0c4d,space(0x20)
2.
3.
Actual results:
కాష్
Expected results:
కా ష్ (without intervening space )
Additional info:
This is common part of telugu /Indian names consisting of Prakash.
substitution should occur only for ka followed by viram and then sha
This problem is present for Pothana2000 also
--
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.
12 years, 9 months