Le Jul 31, 2012 à 9:34 AM, Alan Alpert a écrit :

> On Mon, 30 Jul 2012 19:34:23 ext Jeremy Lainé wrote:
>> I have found QML's network transparency very handy for loading whole UIs
>> over the network, it makes it possible for instance to have "live updates"
>> to an application provided all the changes happen on the QML side. However,
>> once internationalization comes into play, there's a catch: unless I'm
>> mistaken there's currently no way to load Qt's .qm translations straight
>> from QML code.
> 
> Correct. Currently you need to add additional translation loading inside the 
> C++ part of your application.
> 
>> I was therefore thinking of adding a "TranslationLoader" QML element (along
>> the lines of FontLoader) which would have the following properties:
>> 
>> - QUrl source: the URL to the .qm file
>> - enumeration status (Null / Ready / Loading / Error): the loader's status
>> 
>> Any thoughts on such an addition, or on a better API?
> 
> That API looks good. Pretty simple. If the implementation is correspondingly 
> simple, I think such a type would be a welcome addition to QtQml. All you 
> need 
> to do is contribute it through gerrit ;) .
> 

I have put together a simple implementation which is does the basic job, and am 
currently experimenting with it in one of my applications. It brought to light 
a couple of points:

a/ what is the expected behaviour when a new value is assigned to "source": 
uninstall the previous translator (my preference) or just add a new translator, 
keeping the old one?

b/ if any texts have already been run through qsTr, with my current 
implementation they are not be re-translated upon successful loading of the 
translation. Is there a signal or something I can tack onto to trigger a 
retranslation? For now I have worked around this in my application by only 
loading the QML files which require translation once the TranslationLoader has 
finished loading (successfully or with an error).

c/ I noticed that (at least in Qt 4.8) classes such as FontLoader have a 
special code path (protected by ifdefs) for handling local files. Should I be 
doing the same, I was under the impression QNetworkAccessManager already had 
provisions for handling local files?

> PS: To me, CrowdQuick looks like a completely different thing, albiet one 
> which 
> would greatly benefit from a type such as this.
> 

I share your opinion.

Jeremy
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to