Created attachment 416049 [details] wrong czech-symbol in kmix Description of problem: kmix dont correct show czech symbol (wrong coding/ or use font ,I dont know) Version-Release number of selected component (if applicable): kde-l10n-Czech-4.4.3-1.fc13.noarch kde-l10n-4.4.3-1.fc13.noarch kdemultimedia-4.4.3-1.fc13.1.x86_64 kdemultimedia-libs-4.4.3-1.fc13.1.x86_64 How reproducible: everytime Actual results: kmix dont show corect czech symbol Expected results: kmix show corectly czech-symbol or use english-name as default Additional info: systemsetting/phonon show corectly czech symbol
when start paste to konsole kmix(2060): ""CurrencyIntroducedDate" - conversion of "" to QDate failed" " (wrong format: expected 3 items, got 1)" kmix(2060): ""CurrencyIntroducedDate" - conversion of "" to QDate failed" " (wrong format: expected 3 items, got 1)" Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kmix(2060) sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider kmix(2060) sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider
This is a bug in the KMix PulseAudio integration, it should be using QString::fromUtf8 or QString::fromLocal8Bit (I don't know which is more correct, we need to check what PulseAudio does exactly) to convert the device names from PulseAudio. It's using QString::fromLatin1 or QString::fromAscii now, explicitly or implicitly. (Sadly, fromLatin1 is the default for fromAscii, including the implicit fromAscii. They do that because it's faster than fromUtf8 and does the same thing on stuff which is pure 7-bit ASCII, but IMHO defaulting to fromLocal8Bit or fromUtf8 would make more sense. But we have to live with what Qt does, so we need to call the correct function explicitly.)
This is a issue which needs to be reported upstream. Please file a report at http://bugs.kde.org Please add upstream report info to this report. We will monitor the upstream report for a resolution. Thanks for the report -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
We've got a test build on the way to try out: (requires kde-4.4.4 in updates-testing): http://koji.fedoraproject.org/koji/taskinfo?taskID=2251939
Sorry, this would should build better, http://koji.fedoraproject.org/koji/taskinfo?taskID=2251961
Third time is a charm: https://koji.fedoraproject.org/koji/buildinfo?buildID=178240
kdemultimedia-4.4.4-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kdemultimedia-4.4.4-2.fc13
kdemultimedia-4.4.4-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/kdemultimedia-4.4.4-2.fc12
kdemultimedia-4.4.4-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kdemultimedia'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kdemultimedia-4.4.4-2.fc12
kdemultimedia-4.4.4-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kdemultimedia'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kdemultimedia-4.4.4-2.fc13
kdemultimedia-4.4.4-2.fc13 kdemultimedia-4.4.90-1.fc13.x86_64 work ok ,show correct czech symbol
Works ok here as well
kdemultimedia-4.4.4-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
kdemultimedia-4.4.4-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.