On May 21, 2015, 11:29 a.m., Matthew Dawson wrote:
LGTM in general, but could you please add/update a unit test to test all
the possible cominbations of the translation?
Chusslove Illich wrote:
That would make the test depend on the Ki18n framework, which is not
acceptable for tier 1 frameworks.
Alternatively, one could add fake klocalizedstring.h header, to shadow
any system header, and fill it with fake translation calls. But such test
would only check if generated translation call names are as expected, which
is trivially obvious from the code.
Even if it doesn't actually compile the code, I'd like to have something verify
the calls are actually being put in the generated file. It is trivial to see
this RR is correct, but the problem is the future when someone (read: me)
messes up the translation support. I'd like to have something verify that
block does what it should in the future, especially if that block gets a large
refactor.
- Matthew
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123872/#review80698
---
On May 21, 2015, 11:21 a.m., Chusslove Illich wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123872/
---
(Updated May 21, 2015, 11:21 a.m.)
Review request for KDE Frameworks, Alexander Potashev and Matthew Dawson.
Repository: kconfig
Description
---
When using Ki18n as the translation system, library .kcfg files also need to
specify the translation domain. This is analogous to the TRANSLATION_DOMAIN
define in C++ code, and translationDomain attribute in .rc files.
Diffs
-
src/kconfig_compiler/kconfig_compiler.cpp 7160bb5
Diff: https://git.reviewboard.kde.org/r/123872/diff/
Testing
---
Compiles.
Thanks,
Chusslove Illich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
