Bug 11699 – Chinese charactors display error

Bug 11699 - Chinese charactors display error


Summary:	Chinese charactors display error

Status:	RESOLVED FIXED

Product:	Dialcentral
Component:	General
Version:	unspecified
Platform:	N900 Maemo

Importance:	Unspecified normal (vote)
Target Milestone:	---
Assigned To:	Ed Page
QA Contact:	general

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-12-17 18:13 UTC by bing_xia
Modified:	2011-02-08 05:37 UTC (History)
CC List:	1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description bing_xia (reporter) 2010-12-17 18:13:02 UTC

SOFTWARE VERSION: 
(Settings > General > About product)

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. 
2. 
3. 

EXPECTED OUTCOME: 

ACTUAL OUTCOME: 

REPRODUCIBILITY: 
(always, less than 1/10, 5/10, 9/10)

EXTRA SOFTWARE INSTALLED: 

OTHER COMMENTS: 

When fisrt installed several months ago, the contact in simplified chinese form
contact list was displayed correctly. Since the recently several updates,
chinese charaters can no longer displayed. Instead, there is an error message:
! 'sscii' can't encode characters in position 0-5: ordinal no

Comment 1 bing_xia (reporter) 2010-12-17 18:14:12 UTC

However, in the history panel, the contact name in simplified chinese was
displayed correctly.

Comment 2 Ed Page 2010-12-17 18:17:28 UTC

Please follow the bug template.  Things of particular note would be example
text and the version of DC being used.

I think the fix would be fairly easy.  I am probably not using unicode strings.

Comment 3 Ed Page 2010-12-18 17:05:06 UTC

If your complaint is with the 1.1.9X family of DC, I'm now uploading 1.1.97
which makes improvements.  If you could get back with me on whether that helps
or not so we can close out this bug, I'd appreciate it.

Comment 4 Ed Page 2011-02-08 05:37:48 UTC

I've not heard back on this, it looks to be solved, so closing out.