Review Request 118526: Provide i18nd wrappers in kdeclarative

[Martin Gräßlin]

> On June 5, 2014, 10:29 a.m., David Edmundson wrote:
> > +1 from me.
> > The i18nd is definitely useful.
> > 
> > The setTranslationDomain isn't ideal, but there's no 100% nice solution to it.
> >
> 
> David Edmundson wrote:
>     Brainstorming:
>     
>     There is one other possible way we could have i18n automatically select the right catalog, even if you have imports from QML files all over the place.
>     
>      - define all i18n functions in javascript instead of C++
>      - have them do something like
>               function i18n(text) { i18nd(__catalogName, text);
>     
>     then imports or applications or whatever need to declare a:
>      readonly property string __catalogName: "catalogName"
>     somewhere in the root file qml file, as well as in any imported file.
>     
>     Because JS would then be evaluating the catalog name, it would find the variable in the right scope, and thus the right catalogName.
>

it has a disadvantage: if one uses the QML in an application one doesn't want the i18n calls to go through i18nd as KLocalizedString::setApplicationDomain was called.


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