Review Request 118526: Provide i18nd wrappers in kdeclarative

[Marco Martin]

> On June 5, 2014, 8: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).
> 
> Martin Gräßlin wrote:
>     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?
> 
> David Edmundson wrote:
>     Oh yeah, the property isn't writeable.
>     Probably isn't worth it then.

things loaded from c++ like plasmoids and other packages will have the proper domain set.

but anyhthing in imports will always be out of luck and can only use explicitly i18nd, i don't see any other solution sadly


- Marco


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


On June 4, 2014, 1: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, 1: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/b6ab946d/attachment-0001.html>