QObject::tr()

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

QObject::tr()

Ted Felix-2
   If a class no longer derives from QObject, is it OK to change all the
tr() calls to QObject::tr() calls?  Or would it be better to retain the
derivation from QObject (ugly as that may be)?

   (My limited understanding from scanning the mailing lists is that
there is something called a "translation context" and going from tr() to
QObject::tr() changes that.  Or something.  So perhaps this causes
headaches for translators?  Deriving from QObject causes headaches for
me, but I can manage.)

Ted.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

Yves Guillemot
Le vendredi 6 janvier 2017, 14:23:23 Ted Felix a écrit :

>    If a class no longer derives from QObject, is it OK to change all the
> tr() calls to QObject::tr() calls?  Or would it be better to retain the
> derivation from QObject (ugly as that may be)?
>
>    (My limited understanding from scanning the mailing lists is that
> there is something called a "translation context" and going from tr() to
> QObject::tr() changes that.  Or something.  So perhaps this causes
> headaches for translators?  Deriving from QObject causes headaches for
> me, but I can manage.)
>

Insofar as I correctly understand
http://doc.qt.io/qt-5/i18n-source-translation.html
tr() should be used inside a subclass of a QObject and the class name is the
translation context.
Outside a QObject, QCoreApplication::translate() should be used and it's first
argument is the translation context. This translation context may be the class
name or any other string.

The translation context helps the translator to know from where in the code
(and in the GUI) the string needing a translation is coming.

The about 1800 strings coming from the .rc files have the same "QObject"
translation context. Only them are the cause of translators'headaches:)

Yves


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

Ted Felix-2
On 01/06/2017 04:55 PM, Yves Guillemot wrote:
> Le vendredi 6 janvier 2017, 14:23:23 Ted Felix a écrit :
>>    If a class no longer derives from QObject, is it OK to change all the
>> tr() calls to QObject::tr() calls?
> Outside a QObject, QCoreApplication::translate() should be used and it's first
> argument is the translation context. This translation context may be the class
> name or any other string.

   OK, I'm going to go with this for the stuff I'm doing right now.
I'll follow up with a post once I've pushed it to svn so you translation
guys can test it and see if it is working properly.  Worst-case I can go
back to deriving from QObject and use tr().

   (One day I should do a Pig Latin translation for Osegardenray to get
familiar with all this translation stuff.)

Ted.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

D. Michael McIntyre-3
In reply to this post by Yves Guillemot
On 01/06/2017 04:55 PM, Yves Guillemot wrote:

> The translation context helps the translator to know from where in the code
> (and in the GUI) the string needing a translation is coming.
>
> The about 1800 strings coming from the .rc files have the same "QObject"
> translation context. Only them are the cause of translators'headaches:)

Do you really find it helpful that you know you are translating
something like "Quantize" in 15 different contexts?  The QObject context
is gigantic and annoying to manage, but at least strings only appear
once in there.  The kind of context I find meaningful in a translation
is in the comments, like the one about "this is a keyboard shortcut for
an English QWERTY keyboard" and so on like that.  I don't generally care
that this came from some dialog box and that came from some command.

Maybe the context is more useful than I think, and I'm not looking at it
the right way.

--
D. Michael McIntyre

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

D. Michael McIntyre-3
In reply to this post by Ted Felix-2
On 01/06/2017 02:23 PM, Ted Felix wrote:

>    If a class no longer derives from QObject, is it OK to change all the
> tr() calls to QObject::tr() calls?  Or would it be better to retain the
> derivation from QObject (ugly as that may be)?

The update tool USUALLY does a pretty good job of recycling identical
translations that have merely changed contexts.  The translator just has
to skim along and confirm them.  This isn't a large burden.

Feel free to do what makes sense in the code, and I'll help make sure
the translations are still working afterwards.

--
D. Michael McIntyre

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

Yves Guillemot
In reply to this post by D. Michael McIntyre-3
Le vendredi 6 janvier 2017, 21:33:31 D. Michael McIntyre a écrit :
> Do you really find it helpful that you know you are translating
> something like "Quantize" in 15 different contexts?
Indeed most of the time this is not useful.
Nevertheless the meaning of strings may sometimes be unclear out of their
context (at least for me), for example: "Add &Open".
Another problem is the position of the & in the translated string. To choose a
right position whithout knowing all the entries of the menu is difficult. The
only way to solve this problem is to find the menu itself.

> The QObject context
> is gigantic and annoying to manage, but at least strings only appear
> once in there.  The kind of context I find meaningful in a translation
> is in the comments, like the one about "this is a keyboard shortcut for
> an English QWERTY keyboard" and so on like that.
Comments of that sort are invaluable.

> I don't generally care
> that this came from some dialog box and that came from some command.
A too long string may give a weird look to some dialogs. It sometimes is
important to limit the size of the translated string according to the dialog.

> Maybe the context is more useful than I think, and I'm not looking at it
> the right way.

Nothing is insurmountable and I hope I didn't give the impression that
translating RG is more difficult that it really is.
Currently there is no real problem.

BTW I see "D. Michael McIntyre" among the source strings in the QObject
context. Does it really needs a translation ? :)

Yves

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

D. Michael McIntyre-3
On 01/07/2017 07:53 AM, Yves Guillemot wrote:

> Nevertheless the meaning of strings may sometimes be unclear out of their
> context (at least for me), for example: "Add &Open".

A fair point.

> Another problem is the position of the & in the translated string. To choose a
> right position whithout knowing all the entries of the menu is difficult. The
> only way to solve this problem is to find the menu itself.

I just don't even worry about it, honestly.  Pick something.  If it
works, it works, and if it doesn't work, somebody will complain
eventually! :)

> A too long string may give a weird look to some dialogs. It sometimes is
> important to limit the size of the translated string according to the dialog.

True, and I really hate the strings people do with \n in them.  Line
breaks that work well for English may not work well in another language.
  I reworked a ton of those, but many remain.

> Nothing is insurmountable and I hope I didn't give the impression that
> translating RG is more difficult that it really is.
> Currently there is no real problem.

I found it easier to translate under i18n() myself, but we have
thousands of translated strings that were not possible before, so there
are winners and losers.  With most of those strings, the losers are the
translators, but fortunately that ugly chore is behind us.  Never again.
  NEVER AGAIN!  In retrospect, it was probably a stupid goal to be able
to have a Rosegarden with every visible string translated.

In all the side projects I've done over the years, I try to design
really simple and obvious pictographic icons, and avoid strings like the
plague they are.

> BTW I see "D. Michael McIntyre" among the source strings in the QObject
> context. Does it really needs a translation ? :)

There are many random pointless machine-generated strings like that.  I
found it easier to just deal with them in the translation instead of
dealing with them on the scripting side of generating all that nonsense.

On this topic, the Spanish translation features a number of texts that
are radically simplified compared to the English.  I took one look at
the string and said "Who wrote this insane wall of text in the first
place?  That guy is an asshole!"  Of course, I was the one who had
always written the wall of text, without fail.

--
D. Michael McIntyre

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

Ted Felix-2
In reply to this post by Ted Felix-2
On 01/06/2017 09:04 PM, Ted Felix wrote:
> I'll follow up with a post once I've pushed it to svn so you translation
> guys can test it and see if it is working properly.  Worst-case I can go
> back to deriving from QObject and use tr().

   OK, I've pushed the one commit that uses
QCoreApplication::translate(), [r14890].

https://sourceforge.net/p/rosegarden/code/14890/

   It's in MusicXmlExporter which is a bit of a pain to test since it
tends to be pretty fast.  You'll need a large composition and a slow
machine to get the progress dialog to appear.  (Worst case you can force
a sleep() or two for testing.)

   This introduces a new string for translation "Writing score part..."
which is used to differentiate between the two parts of the export
process.  I have no idea if that name makes any sense.  Someone more
familiar with the MusicXML export process can probably pick a better
message.

   The question for the translators is, is this OK when translating?
And does it work at runtime?

Ted.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

D. Michael McIntyre-3
On 01/09/2017 08:10 PM, Ted Felix wrote:

>    The question for the translators is, is this OK when translating?
> And does it work at runtime?

Yes, and yes.  You don't need a slow machine, just copy the Hallelujah
Chorus until you fill up 1000 bars, and that makes for quite a nice grind.

--
D. Michael McIntyre

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

D. Michael McIntyre-3
In reply to this post by Ted Felix-2
>    The question for the translators is, is this OK when translating?
> And does it work at runtime?

Incidentally, the old string was preserved, and just had to be
confirmed.  The strings showed up in a new context called MusicXML, and
they don't have a Rosegarden:: anything in front of them.  Interesting.

--
D. Michael McIntyre

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

Ted Felix-2
On 01/09/2017 08:31 PM, D. Michael McIntyre wrote:
> Incidentally, the old string was preserved, and just had to be
> confirmed.  The strings showed up in a new context called MusicXML, and
> they don't have a Rosegarden:: anything in front of them.

   I wasn't sure whether to add "Rosegarden::" to the front of the
context string.  It can easily be added if its useful.  Since
everything's in that namespace, it seemed redundant to me at the time.

Ted.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

D. Michael McIntyre-3
On 01/09/2017 08:38 PM, Ted Felix wrote:

>    I wasn't sure whether to add "Rosegarden::" to the front of the
> context string.  It can easily be added if its useful.  Since
> everything's in that namespace, it seemed redundant to me at the time.

I was thinking more along the lines of I wonder if it's worth rewriting
half the universe to get control over the translation context.  It's
almost tempting.  Almost.  Not quite though.

That worked out pretty well.  It's cleaner, without the redundancy or
globbing even more strings into the gigantic QObject context, but
switching everything around would be complex.  There must be some way to
get control of all that context nonsense without having to
QCoreApplication::translate() everywhere, but maybe there isn't.  We
definitely wouldn't want to make future developers do that much work.
It's hard enough to get anybody to make strings translate as it is.  I
have to go back and fix a lot of things.  Especially from the more minor
contributors.

Just the prattling of a man up too early from much too little sleep,
facing another 14 hour day.

--
D. Michael McIntyre

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Reply | Threaded
Open this post in threaded view
|

Re: QObject::tr()

David Faure
On lundi 9 janvier 2017 23:54:26 CET D. Michael McIntyre wrote:
>  There must be some way to
> get control of all that context nonsense without having to
> QCoreApplication::translate() everywhere, but maybe there isn't.

Note that you can use Q_DECLARE_TR_FUNCTIONS in classes that don't derive from
QObject, so you almost never need to spell out the full
QCoreApplication::translate() ... except in main() itself.

But yeah that's not "get control" as in "choosing something different from the
class name", in the case of QObjects. The only way to get rid of classnames is
to switch to gettext ;-)

--
David Faure, [hidden email], http://www.davidfaure.fr
Working on KDE Frameworks 5


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rosegarden-devel mailing list
[hidden email] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel