Opened 10 years ago

Closed 9 years ago

#7815 closed defect (fixed)

Terra theme uses UTF-8 in "Playback starting" message

Reported by: malcolm.parsons@… Owned by: stuartm
Priority: trivial Milestone: 0.23
Component: Themes Version: 0.22-fixes
Severity: low Keywords:
Cc: Ticket locked: no

Description

Changeset http://cvs.mythtv.org/trac/changeset/22606 changed "..." to "…" in the "Playback starting ..." message.

Mythbuntu's build of 0.22-fixes displays this as "Playback starting …".

I expect this changeset also broke all the translations of this message.

Change History (13)

comment:1 Changed 10 years ago by stuartm

Priority: minortrivial
Severity: mediumlow

It was changed at the request of a translator who suggested that the elipsis character was preferable to dot-dot-dot. Yes Terra uses UTF-8, this isn't the problem, it's perfectly correct (character set is correctly declared at the start of the document). I'm happy to change it back, but I be even happier to get to the bottom of why it's incorrectly displayed, QT bug perhaps?

comment:2 Changed 10 years ago by malcolm.parsons@…

mythuitext.cpp calls qPrintable() on the value string:

if (element.attribute("lang","").isEmpty()) {

m_Message = qApp->translate("ThemeUI",

qPrintable(getFirstText(element)));

} else if ...

comment:3 Changed 10 years ago by stuartm

Nice catch, we don't want to use the value from translate() when it's untranslated.

m_Message = qApp->translate("ThemeUI", qPrintable(getFirstText(element)));
QString tmp = getFirstText(element);
if (m_Message == qPrintable(tmp))
    m_Message = tmp;

is a little messy, but the only solution I can see right now.

comment:4 Changed 10 years ago by stuartm

Owner: changed from Isaac Richards to stuartm
Status: newassigned

Well obviously moving up the assignment to tmp up a line avoids an additional call to getFirstText() ...

comment:5 Changed 10 years ago by Malcolm Parsons <malcolm.parsons@…>

Would this work?

m_Message = qApp->translate("ThemeUI", getFirstText(element).toUtf8(), null, QCoreApplication::UnicodeUTF8);

comment:6 Changed 10 years ago by stuartm

Milestone: 0.22.10.23

comment:7 Changed 10 years ago by stuartm

Status: assignedaccepted

Malcom that fix would force themes to use UTF-8 or a compatible encoding. I don't expect themes to use anything else, but there is no reason to restrict them either, we should be able to accept any encoding so long as the xml charset declaration is correct. I'll go with my suggested fix in this case.

comment:8 Changed 10 years ago by stuartm

On a second reading I realise I was wrong, Malcolm's proposed fix wouldn't restrict the original charset since the conversion to unicode would have already happened by that point, however I'll still go with the other fix since it would avoid two unnecessary character encoding changes on the string in most cases.

comment:9 Changed 10 years ago by stuartm

Resolution: fixed
Status: acceptedclosed

(In [23970]) Fix the display of non-Latin1 strings in the UI when no translation was available. After some thought (coffee) I went with the fix suggested by Malcolm Parsons as it was the most logical and neatest solution. I will backport once I'm certain that it doesn't break anything. Fixes #7815

comment:10 Changed 9 years ago by malcolm.parsons@…

Resolution: fixed
Status: closednew

I'm using 0.23-fixes, the Playback starting message is still displayed incorrectly.

See also ticket 8581.

comment:11 Changed 9 years ago by stuartm

Resolution: fixed
Status: newclosed

Closing as a duplicate of #8581, this was fixed for linux, ongoing problems seem to be specific to OSX.

comment:12 Changed 9 years ago by malcolm.parsons@…

Resolution: fixed
Status: closednew

I am on Linux.

comment:13 Changed 9 years ago by stuartm

Resolution: fixed
Status: newclosed

(In [25145]) Backport [23970] to 0.23-fixes. Fix the display of non-Latin1 strings in the UI when no translation was available. Fixes #7815

Note: See TracTickets for help on using tickets.