[Interest] Dynamic translations for mobile apps at runtime?

Jérôme Godbout jerome at bodycad.com
Fri Mar 4 15:06:29 CET 2016


>  "-tr-function-alias qsTr=MySingleton.myqsTr"
That's what I tried but it didn't work sadly. That would have solve it
nicely.

On Thu, Mar 3, 2016 at 5:43 PM, Jason H <jhihn at gmx.com> wrote:

> What if you did "-tr-function-alias qsTr=MySingleton.myqsTr" ?
>
> *Sent:* Thursday, March 03, 2016 at 5:31 PM
> *From:* "Jérôme Godbout" <jerome at bodycad.com>
> *To:* "Julien Cugnière" <julien.cugniere at gmail.com>
> *Cc:* "interest at qt-project.org" <interest at qt-project.org>
> *Subject:* Re: [Interest] Dynamic translations for mobile apps at runtime?
> I test it out, it work as long as the function is a direct function
> access, you can't use module call like
>
> MySingleton.myqsTr("My String") // don't work, lupdate does get this one
> myqsTr("My String") // work
>
> Could have put the function into it's own javascript .pragma library and
> just import it in needed file. Is their a way to declare a global
> javascript function into the engine with the binding still working? I just
> don't want to add the function on each file if possible:
>
> *function myqsTr(str) { return qsTr(str) + I18n.revaluate; }*
>
> I may try to add the function into the RootItem of the QQuickView and hope
> the context hierarchies will always find it everywhere to see if this work.
>
> That's so close to work well...
>
>
>
> On Thu, Mar 3, 2016 at 3:41 PM, Jérôme Godbout <jerome at 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.cugniere at gmail.com> wrote:
>>>
>>> 2016-03-03 18:50 GMT+01:00 Jérôme Godbout <jerome at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160304/6301939b/attachment.html>


More information about the Interest mailing list