[Fedora-i18n-bugs] [Bug 499790] [te_IN][pango]GSUB delete key can't delete the whole char in f10
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=499790
Akira TAGOH <tagoh(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |NOTABUG
Last Closed| |2014-10-09 05:16:55
--- Comment #10 from Akira TAGOH <tagoh(a)redhat.com> ---
After taking a look at UAX#29 and the Pango code, current behavior is following
the Unicode standard unfortunately.
Here is the details how the text segmentation is decided in Pango according to
the standard:
First, the character type for the above characters are:
U+0C15 OTHER LETTER
U+0C4D NON SPACING MARK
Pango is looking at the grapheme boundary rule to decide if a character should
be deleted by backspace key. it's defined as following in UAX#29:
* Break at the start(GB1) and end(GB2) of text.
* Do not break between a CR and LF(GB3). Otherwise, break before(GB4) and
after(GB5) controls.
* Do not break Hangul syllable sequences(GB6,GB7,GB8).
* Do not break between regional indicator symbols(GB8a).
* Do not break before extending characters(GB9).
Only for extended grapheme clusters:
* Do not break before SpacingMarks(GB9a), or after Prepend characters(GB9b).
* Otherwise, break everywhere.
According to the table 2 in UAX#29, non-spacing mark is categorized into
Extend. so it doesn't break *before* U+0C4D. but no rules to not break *after*
Extend.
At this point, there are no standard that the software can refers the material
to prevent that behavior. maybe good to escalate this to Unicode.org then.
--
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=utekeuJBL3&a=cc_unsubscribe
9 years, 6 months
[Fedora-i18n-bugs] [Bug 1147535] New: All C octal escaped UTF-8 chars converted to arab unicode char yeh barree
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1147535
Bug ID: 1147535
Summary: All C octal escaped UTF-8 chars converted to arab
unicode char yeh barree
Product: Fedora
Version: 21
Component: gettext
Assignee: dueno(a)redhat.com
Reporter: kmaraas(a)gnome.org
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, praiskup(a)redhat.com
Description of problem:
Some time recently I started seeing the arabic yeh barree character ے being
inserted into my Norwegian bokmål translations for GNOME instead of the actual
other octal escaped UTF-8 chars are in the source files.
I'm guessing xgettext has problems for some reason. I tried running
intltool-update using LC_ALL=C to see if it was locale related, but that gave
the same result.
Version-Release number of selected component (if applicable):
[kmaraas@localhost po (master *)]$ rpm -q gettext
gettext-0.19.2-2.fc21.x86_64
[kmaraas@localhost po (master *)]$ rpm -q intltool
intltool-0.50.2-8.fc21.noarch
[kmaraas@localhost po (master *)]$
How reproducible:
Every time.
Steps to Reproduce:
1. run intltool-update -p in a module that has C octal escaped UTF-8 chars in
the source code
2. check the resulting .pot file
3.
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=pL7eri0IEo&a=cc_unsubscribe
9 years, 6 months