You will have the same overhead whenever the text to translate changes. If
it is static during the application life cycle then this should not be an
issue either.
On Thu, Mar 3, 2016 at 11:41 PM Jérôme Godbout <jer...@bodycad.com> wrote:
> Nice, I didn't knew about "-tr-function-alias", indeed this seem like the
> right thing to do. Will try this out. About speed, for the number of time
> you use the change language during runtime, it doesn't really matter, if it
> take a few ms more.
>
> Thanks for the tips!
>
> On Thu, Mar 3, 2016 at 2:37 PM, Julien Cugnière <julien.cugni...@gmail.com
> > wrote:
>
>> 2016-03-03 18:50 GMT+01:00 Jérôme Godbout <jer...@bodycad.com>:
>> > We did the same thing into Qml, we have a C++ singleton equivalent to
>> your
>> > backend, that select the current language files and emit the QString
>> > property changed.
>> > qsTr("String to convert") + I18n.revaluate
>> >
>> > I wish they made underlying hook to revaluate the qsTr() with a signal
>> > connected like if the qsTr() have changed. This pollute the code all
>> over,
>> > only to be able to swap language on the fly.
>>
>> Just an idea : you might be able to hide that I18n.revaluate with
>> something along the lines of :
>>
>> function myTr(s) {
>> return qsTr(s) + I18n.revaluate;
>> }
>>
>> Text {
>> text: myTr("String to convert")
>> }
>>
>> Then you need to get lupdate to understand "myTr", which can be done
>> with the command line option "-tr-function-alias qsTr=myTr".
>>
>> Although this incurs the overhead of a function call, which might
>> prevent QML from using its fast path for bindings evaluation. Not sure
>> if it matters.
>>
>> Julien Cugnière
>>
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
