This seems wrong to me. I assume that according to the returned value, the relevant icon is selected for display => it is expected that the name corresponds to the files of icons and therefore not translated as a string.
This seems wrong to me. I assume that according to the returned value, the relevant icon is selected for display => it is expected that the name corresponds to the files of icons and therefore not translated as a string.
I believe that the use of i18n() in these cases is not wanted. It is not clear here what the msg will contain, and therefore in this application such a msg is not part of the translation catalog => call i18n() does not make sense inside a slot. If the message is to be translated, then call i18n() should be made on the side that causes invacation of the slot.
I believe that the use of `i18n()` in these cases is not wanted. It is not clear here what the `msg` will contain, and therefore in this application such a `msg` is not part of the translation catalog => call `i18n()` does not make sense inside a slot. If the message is to be translated, then call `i18n()` should be made on the side that causes invacation of the slot.
I will force push now with the changes also mentioned above - I agree - I did it automatically and did not think to much that in this case it is not desired.
it did not want to compile without it :(
I will force push now with the changes also mentioned above - I agree - I did it automatically and did not think to much that in this case it is not desired.
Actually, there is another question: Where do these error messages come from? Where do these texts have the opportunity to become a part of the translation template? On closer look, it seems to me that all these occurrences trying to translate unknown content of property are not desirable.
Either the messages are already translated by the one who returns them or it is not possible to translate their content because they are not part of the translation template.
This also applies to cases such as i18n(msg.utf8()).local8Bit() above.
Actually, there is another question: Where do these error messages come from? Where do these texts have the opportunity to become a part of the translation template? On closer look, it seems to me that all these occurrences trying to translate unknown content of property are not desirable.
Either the messages are already translated by the one who returns them or it is not possible to translate their content because they are not part of the translation template.
This also applies to cases such as `i18n(msg.utf8()).local8Bit()` above.
tdeio_obex is intended to be used either in konqueror (as extention) or in the command line utility tdebluezioclient
The commandhandler.cpp is the implementation for tdebluezioclient.
I hope this helps
tdeio_obex is intended to be used either in konqueror (as extention) or in the command line utility tdebluezioclient
The commandhandler.cpp is the implementation for tdebluezioclient.
I hope this helps
What I meant that the message would arise in the application on the opposite side of the dbus interface, and that this application should take care of whether the message will be translated. On our side of the recipient we cannot know what messages we get and therefore we cannot ensure their translations.
What I meant that the message would arise in the application on the opposite side of the dbus interface, and that this application should take care of whether the message will be translated. On our side of the recipient we cannot know what messages we get and therefore we cannot ensure their translations.
OK, this is valid point. I will look forward to go through the changes and evaluate the context. So where the the messages are to be used locally, we translate and where send to the remote part, we don't. This makes sense.
thanks
OK, this is valid point. I will look forward to go through the changes and evaluate the context. So where the the messages are to be used locally, we translate and where send to the remote part, we don't. This makes sense.
thanks
Now I have noticed – these strings become part of the message that is displayed using KNotify and is TQString in UTF-8. Therefore .local8Bit().data() looks like unwanted.
Now I have noticed – these strings become part of the message that is displayed using KNotify and is TQString in UTF-8. Therefore `.local8Bit().data()` looks like unwanted.
@SlavekB
interestingly, I just noticed that it complains about the type, but compiles
this is why I had to use .local8Bit().data() there
./src/tdebluez/devicewizard.cpp: In member function ‘void DeviceWizard::slotAsyncErrorResponseDetected(int, TQT_DBusError)’:
../src/tdebluez/devicewizard.cpp:741:51: warning: format ‘%s’ expects argument of type ‘char*’, but argument 4 has type ‘TQString’ [-Wformat=]
741 | tqDebug("AsyncErrorResponseDetected (%i): %i %s %s", asyncCallId, dbuserr.type(), dbuserr.name(), dbuserr.message());
@SlavekB
interestingly, I just noticed that it complains about the type, but compiles
this is why I had to use .local8Bit().data() there
```
./src/tdebluez/devicewizard.cpp: In member function ‘void DeviceWizard::slotAsyncErrorResponseDetected(int, TQT_DBusError)’:
../src/tdebluez/devicewizard.cpp:741:51: warning: format ‘%s’ expects argument of type ‘char*’, but argument 4 has type ‘TQString’ [-Wformat=]
741 | tqDebug("AsyncErrorResponseDetected (%i): %i %s %s", asyncCallId, dbuserr.type(), dbuserr.name(), dbuserr.message());
```
@SlavekB
interestingly, I just noticed that it complains about the type, but compiles
There are three types of tqDebug() calls. One takes a const char*, one a TQCString and one a TQString.
The one you are using is the const char* type, so you need to pass a const char* to a %s argument. dbuserr.name() returns a TQString, which is not implicitly converted to const cahr*, hence the need to use .local8Bit().data().
Alternatively, you can use the version that takes a TQString, but with many parameters to conactenate it becames less readable.
> @SlavekB
> interestingly, I just noticed that it complains about the type, but compiles
There are three types of tqDebug() calls. One takes a const char*, one a TQCString and one a TQString.
The one you are using is the const char* type, so you need to pass a const char* to a %s argument. dbuserr.name() returns a TQString, which is not implicitly converted to const cahr*, hence the need to use .local8Bit().data().
Alternatively, you can use the version that takes a TQString, but with many parameters to conactenate it becames less readable.
yes, indeed I now removed translation of these messages (see last commit). As far as I understand i18n provides the strings that are translated in weblate. So it does not make any sense to as i18n to translate something we do not know.
Let me know if you find anything else or if I am wrong in my understanding. And thank you, I learned a lot now. I hope I do not forget it soon.
yes, indeed I now removed translation of these messages (see last commit). As far as I understand i18n provides the strings that are translated in weblate. So it does not make any sense to as i18n to translate something we do not know.
Let me know if you find anything else or if I am wrong in my understanding. And thank you, I learned a lot now. I hope I do not forget it soon.
After corrections corrections corrections it looks good good good 😺.
It's time to make squash commits and then we can move forward and merge it.
glad to see a smile on your face.
squashed and force-pushed.
BR
> After corrections corrections corrections it looks good good good 😺.
> It's time to make squash commits and then we can move forward and merge it.
glad to see a smile on your face.
squashed and force-pushed.
BR
MicheleC
SlavekB
Signed-off-by: Emanoil Kotsev deloptes@gmail.com
Good work. However, you can find some comments here.
TQDateTime date = TQDateTime::currentDateTime();TQString user = "n/a";TQString iconName = i18n("unknown");This seems wrong to me. I assume that according to the returned value, the relevant icon is selected for display => it is expected that the name corresponds to the files of icons and therefore not translated as a string.
}if (args->isSet("iconName")){std::cout << i18n(iconName.local8Bit()).local8Bit() << " ";The same as the previous one. At the same time, you may notice that this will potentially try to translate the already translated string unknown.
}if (args->isSet("linkdest")){std::cout << i18n(linkDest.local8Bit()).local8Bit() << " ";I assume that this is the name of the target file / directory referred to by symlink. In this case, it is not desirable to attempt to translate.
}if (args->isSet("name")){std::cout << i18n(name.local8Bit()).local8Bit() << " ";I suppose this is the name of the file / directory. In this case, it is not desirable to attempt to translate.
}if (args->isSet("xmlproperties")){std::cout << i18n(xmlProperties.local8Bit()).local8Bit() << " ";It is likely that this is not desirable to attempt to translate.
}if (args->isSet("extra")){std::cout << i18n(extra.local8Bit()).local8Bit() << " ";It is likely that this is not desirable to attempt to translate.
{if (msg != lastMessage && args->isSet("messages")){std::cerr << " >" << i18n(msg.local8Bit()).local8Bit() << std::endl;Function
i18n(...)expects the input string in UTF-8, not local8bit.I believe that the use of
i18n()in these cases is not wanted. It is not clear here what themsgwill contain, and therefore in this application such amsgis not part of the translation catalog => calli18n()does not make sense inside a slot. If the message is to be translated, then calli18n()should be made on the side that causes invacation of the slot.{if (job->error() != 0){std::cerr << i18n(job->errorString().local8Bit()).local8Bit() << std::endl;Function
i18n(...)expects the input string in UTF-8, not local8bit.void CommandHandler::exitPrintUsage(const TQString& message){std::cout << i18n(message.local8Bit()).local8Bit() << std::endl;Function
i18n(...)expects the input string in UTF-8, not local8bit.if (!mClient->RemoveSession(mSessionPath, dbuserror)){if (dbuserror.isValid())TDEIO::SlaveBase::error(TDEIO::ERR_COULD_NOT_CONNECT, i18n(dbuserror.message().local8Bit()));I didn't look at it in detail, but the call
local8bit()seems wrong to me.it did not want to compile without it :(
I will force push now with the changes also mentioned above - I agree - I did it automatically and did not think to much that in this case it is not desired.
Actually, there is another question: Where do these error messages come from? Where do these texts have the opportunity to become a part of the translation template? On closer look, it seems to me that all these occurrences trying to translate unknown content of property are not desirable.
Either the messages are already translated by the one who returns them or it is not possible to translate their content because they are not part of the translation template.
This also applies to cases such as
i18n(msg.utf8()).local8Bit()above.tdeio_obex is intended to be used either in konqueror (as extention) or in the command line utility tdebluezioclient
The commandhandler.cpp is the implementation for tdebluezioclient.
I hope this helps
What I meant that the message would arise in the application on the opposite side of the dbus interface, and that this application should take care of whether the message will be translated. On our side of the recipient we cannot know what messages we get and therefore we cannot ensure their translations.
OK, this is valid point. I will look forward to go through the changes and evaluate the context. So where the the messages are to be used locally, we translate and where send to the remote part, we don't. This makes sense.
thanks
There are other little things.
See the comments below.
"ConnectionError", i18n("AsyncErrorResponseDetected: %1\n%2\n%3").arg(error.type()).arg(error.name().local8Bit().data()).arg(error.message().local8Bit().data()));Now I have noticed – these strings become part of the message that is displayed using KNotify and is TQString in UTF-8. Therefore
.local8Bit().data()looks like unwanted."ConnectionError", i18n("AsyncErrorResponseDetected: %1\n%2\n%3").arg(dbuserr.type()).arg(dbuserr.name().local8Bit().data()).arg(dbuserr.message().local8Bit().data()));The same case as above –
.local8Bit().data()looks like unwanted.@SlavekB
interestingly, I just noticed that it complains about the type, but compiles
this is why I had to use .local8Bit().data() there
There are three types of tqDebug() calls. One takes a const char*, one a TQCString and one a TQString.
The one you are using is the const char* type, so you need to pass a const char* to a %s argument. dbuserr.name() returns a TQString, which is not implicitly converted to const cahr*, hence the need to use .local8Bit().data().
Alternatively, you can use the version that takes a TQString, but with many parameters to conactenate it becames less readable.
352b2a3e03to593ca27e2b1 year agoThere is one small thing and the use of
i18n()for unknown messages in slots.// }// if (error.isValid())// tqDebug("Failed in connecting device: %s", error.message().local8Bit().data());// tqDebug("Failed in connecting device: %s", error.message());.local8Bit().data()is removed, but message is not wrapped ini18n().See my last commit.
Yes, now it looks good. Please pay attention to the comment 24068 on src/tdebluezioclient/commandhandler.cpp.
yes, indeed I now removed translation of these messages (see last commit). As far as I understand i18n provides the strings that are translated in weblate. So it does not make any sense to as i18n to translate something we do not know.
Let me know if you find anything else or if I am wrong in my understanding. And thank you, I learned a lot now. I hope I do not forget it soon.
After corrections corrections corrections it looks good good good 😺.
It's time to make squash commits and then we can move forward and merge it.
35d3d4f57btob064e1e2001 year agoglad to see a smile on your face.
squashed and force-pushed.
BR
b064e1e200toc95a4298261 year agoc95a429826into master 1 year agoAfter squash all looks good...
...and already merged 😸
Reviewers
c95a429826.