> On Oct. 15, 2016, 4:05 p.m., David Faure wrote: > > src/k7zip.cpp, line 2343 > > <https://git.reviewboard.kde.org/r/129170/diff/3/?file=482230#file482230line2343> > > > > QObject::tr() is bad practice in Qt code (the context class name is > > then "QObject" instead of e.g. K7Zip). > > > > However I assume that our ts -> po tools don't really care about the > > context classname (since po doesn't have that), so maybe it doesn't matter. > > It still shows bad practice for people actually using lupdate. > > > > (BTW the solution for the fact that this isn't a QObject-derived class > > is to add Q_DECLARE_TR_FUNCTIONS to the class definition) > > Friedrich W. H. Kossebau wrote: > The ts -> po tools make extra efforts to indeed care about the context :) > Cmp. > https://websvn.kde.org/trunk/l10n-kf5/templates/messages/frameworks/kcoreaddons5_qt.pot?view=markup > and see the extra tags `#, qt-format` and `msgctxt "KAboutLicense|"`, which > lconvert then uses for creating qm files with the context as wanted. > > So best no QObject::tr(), but using Q_DECLARE_TR_FUNCTIONS when needed, > indeed. Especially for apps linking to lots of libs that use > QTranslator-based translations, having different context is important to > avoid clashes for common terms.
Thanks for the info, I wasn't aware of `Q_DECLARE_TR_FUNCTIONS`. > On Oct. 15, 2016, 4:05 p.m., David Faure wrote: > > src/k7zip.cpp, line 2874 > > <https://git.reviewboard.kde.org/r/129170/diff/3/?file=482230#file482230line2874> > > > > As previously discussed, I think this should (also) be a qWarning. > > > > API misuse => qWarning. > > > > Reasoning: if a bad programmer misuses the API *and* doesn't check > > errorString, he/she won't find out. > > > > And the tr() string might need adjustment, this is shown the user, but > > the "you" in the string isn't the user. I'd say > > > > setErrorString(tr("Application error: 7-Zip file not open before > > writing to it, please file a bug report at https://bugs.kde.org")) Why was the `qWarning` commented out in the first place, though? Should we bring it back? > And the tr() string might need adjustment, this is shown the user, but the > "you" in the string isn't the user. Makes sense. > file a bug report at https://bugs.kde.org I think this implies the application using the library is a KDE App, which isn't necessarily the case. - Romário ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129170/#review100017 ----------------------------------------------------------- On Oct. 15, 2016, 3:08 a.m., Romário Rios wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129170/ > ----------------------------------------------------------- > > (Updated Oct. 15, 2016, 3:08 a.m.) > > > Review request for KDE Frameworks. > > > Repository: karchive > > > Description > ------- > > This method is similar to `QIODevice::errorString()`. I added a public > `errorString()` method and a protected `setErrorString()` method, to allow > `KArchive`'s subclasses to implement their own error messages. I also > implemented most error messages from most subclasses. > > > Diffs > ----- > > autotests/karchivetest.cpp d0fbf41 > src/k7zip.cpp 692b1db > src/kar.cpp 7204fb1 > src/karchive.h b528a4a > src/karchive.cpp a1a160a > src/karchive_p.h 256620d > src/krcc.cpp 1947dd6 > src/ktar.cpp f70b155 > src/kzip.cpp 94d4276 > > Diff: https://git.reviewboard.kde.org/r/129170/diff/ > > > Testing > ------- > > I added `QVERIFY` calls after all errors in `karchivetests.cpp`. Perhaps > we'll need more tests, but I'm not sure how to make an archive to fail in > some specific way aside from the very basics ("file not found", etc.). > > > Thanks, > > Romário Rios > >