Hey folks,
I’ve started looking into plugin development recently and was wondering what the intended way of localizing and translating application plugins is.
Loading a translation file during runtime doesn’t seem to be doable from within QML. Although just because I didn’t manage to do it doesn’t mean it’s not possible, since I’m still fairly new to programming in QML.
There are two other options I could think of:
-
Submitting my plugin translations to the official QField Transifex, which seems inappropriate.
-
Building my own translation system, which, even though it would probably just be a simple map, feels unnecessary when QML/Qt has localization capabilities built in.
Option 2 is probably what I’ll go with for now.
Curious to hear how others are approaching this, or if I’ve missed anything obvious. Any tips, insights, or examples would be very much appreciated!
hey @fggs-pascal
I’ll let @Mathieu_Pellerin take a stance here. I agree with you that option #1 is very likely not a desired outcome.
Cheers
Marco
@fggs-pascal , option #1 is definitively not an option. It wouldn’t scale over time, and we’d create extra burden for QField translators who should be focused on translating QField itself.
Building your own translation system is an interesting challenge
I wouldn’t be surprised if there’s a javascript l18n library out there that’d already be compatible with Qt’s QML Javascript engine, I’d check that out (e.g. https://formatjs.github.io/). I’d temper expectations though, the QML Javascript engine isn’t super up-to-date.
Otherwise, there would also be the possibility to develop some invokable functions in QField (attached to the iface object) to add / manage / remove QTranslator objects via QCoreApplication::installTranslator. That’s something that’d require some development time 
2 Likes