> On June 5, 2014, 8:58 a.m., Chusslove Illich wrote: > > src/kdeclarative/private/rootcontext.cpp, line 48 > > <https://git.reviewboard.kde.org/r/118526/diff/1/?file=278659#file278659line48> > > > > (And at other places like this.) > > > > If I understand, any of the parameters can be not given (isNull()) in > > the call, and therefore the original code does ki18n() followed by checks > > and .subs(). The patch should then behave in the same way, i.e. > > > > KLocalizedString trMessage; > > if (!m_translationDomain.isNull()) { > > trMessage = ki18nd(m_translationDomain, > > message.toUtf8().constData()); > > } else { > > trMessage = ki18n(message.toUtf8().constData()); > > } > >
Seems a good point - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118526/#review59287 ----------------------------------------------------------- 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel