Translatable strings in unexpected context
-
I have a class StackingDlg in namespace DSS.
In the code for StackingDlg I use the tr() macro.
The translatable strings are being placed in the DSS context, rather than DSS::StackingDlg as I would expect.
I wrote:
QString message{ tr("Do you really want to permanently erase %n file(s)?\n" "This operation cannot be reversed or cancelled.", "IDS_WARNING_ERASEFILES", rowCount) };Which expanded to QString message { QString DSS::StackingDlg::tr( etc... ) };
So I think it should not have been placed into DSS!
Why might this happening?
-
First,
tr()is not a macro. It's a member function of class DSS::StackingDlg. It callsQMetaObject::trof that class staticMetaObject, which usesQMetaObject::classNamefor the context. Class name is "DSS::StackingDlg", so everything is as it should. -
But it isn't - those entries should be in context DSS::StackingDlg not DSS shouldn't they?
All the other classes I have in that namespace place their translatables into DSS::ClassName context!
David
those entries should be in context DSS::StackingDlg not DSS shouldn't they?
They should and they are for me. Can you make a small reproducible example when that doesn't happen?
-
I wish I could - I've been banging my head on it for some hours.
I have zipped up StackingDlg.cpp and .h and uploaded the zip file to:
http://www.perdrix.co.uk/StackingDlg.zip
I know they won't compile, but I think you should be able to run lupdate against them.
-
It works like this:
namespace DSS { class StackingDlg : public QObject { void foo() { tr("Works!"); } }; }so you must be doing something else in your code. I can't help you with code I can't see, sorry.
-
I wish I could - I've been banging my head on it for some hours.
I have zipped up StackingDlg.cpp and .h and uploaded the zip file to:
http://www.perdrix.co.uk/StackingDlg.zip
I know they won't compile, but I think you should be able to run lupdate against them.
@Perdrix
Looking at your looooooong file ,
since your using the Designer for this dialog, I think you must specify the namespace in the "Promote To" dialog for the "Promoted class name" field.Here what I am doing with custom classes in a namespace:

-
Well... that's odd :-)
I did a little bit of testing. There's a line in
StackingDlg::eventFiltermethod like this:if (QKeyEvent::matches(QKeySequence::keyBindings(QKeySequence::SelectAll))QKeyEvent::matchesis not static, so this should rather bekeyEvent->matches(..., but that's beside the point.
This code is inside#if (0), so it shouldn't matter at all, but for whatever reason it seems to trip the linguist parser.
If I comment that line out or remove it entirely the context for the entire class is fixed.I guess you've struck some odd corner case bug in the parser? I've no idea, but that's how you can workaround it.
Btw. you have code like this in couple places:
OUTPUTLIST_FILTERS.append(tr(filter.toLocal8Bit(), "IDS_LISTFILTER_OUTPUT"));This will not translate. Linguist is an offline tool. It can't gather dynamically resolved strings like that. You need to translate the source strings and use them already translated.
-
How on earth did you find out what was wrong?
Just the usual - divide and conquer. Since the simple example I posted worked I started to remove large chunks of code until it worked. When it did I added a little bit back and so on. At the end it turned out to be just that one line that made difference. Good thing the code doesn't need to be complete or compile for linguist to work on it.
Reduction is often a good debugging tool :)
EDIT Hah, I just spotted what the issue is. Count the number of opening and closing brackets in that line. It's missing the last closing ), so the parser got lost. So it's not a linguist issue after all. That's good.
-
Nice one thanks again.
Also for the pointer to the issue with the use of tr(). Is there a clean way to resolve that?
David
You need to mark the source strings for translation. See QT_TRANSLATE_NOOP macro. It's for this exact case.
