Review Request 118526: Provide i18nd wrappers in kdeclarative

Martin Gräßlin mgraesslin at kde.org
Thu Jun 5 08:37:45 UTC 2014



> On June 5, 2014, 10:29 a.m., David Edmundson wrote:
> > src/kdeclarative/kdeclarative.cpp, line 120
> > <https://git.reviewboard.kde.org/r/118526/diff/1/?file=278657#file278657line120>
> >
> >     Can we warn if this is already set to something else.
> >     
> >     If two QML files try to do it to different paths it means something has gone horribly wrong (or is just about to).

As the method is only supposed to be called before setupBindings I'm not sure whether a warning will help anything. @Marco: your opinion on it?


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118526/#review59257
-----------------------------------------------------------


On June 4, 2014, 3:06 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> -----------------------------------------------------------
> 
> (Updated June 4, 2014, 3:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> -------
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -----
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 123066669b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> -------
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140605/b80d9446/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list