[Interest] Dynamic translations for mobile apps at runtime?

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


Just to be clear, the lupdate did not found the string and skip it, nothing
new is found or updated. The usage after work properly.

On Fri, Mar 4, 2016 at 9:06 AM, Jérôme Godbout <jerome at bodycad.com> wrote:

> >  "-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/e90fa7cb/attachment.html>


More information about the Interest mailing list