Review Request 110865: KConfig: fix long-standing bug where translations would not be loaded.

[Oswald Buddenhagen]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110865/#review34612
-----------------------------------------------------------

Ship it!


i cannot claim i would understand the relation with the higher-level cascading without reading all the code again, but at this low level, the change is logically correct afaict.

- Oswald Buddenhagen


On June 7, 2013, 1:28 p.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110865/
> -----------------------------------------------------------
> 
> (Updated June 7, 2013, 1:28 p.m.)
> 
> 
> Review request for kdelibs and Oswald Buddenhagen.
> 
> 
> Description
> -------
> 
> KConfig: fix long-standing bug where translations would not be loaded.
> 
> This happened in the following situation:
> * KDEDIRS with two prefixes (let's call them global and middle)
> * a kconfig file with the same name in both (e.g. a .desktop file)
> * same value for Name[locale]= in both
> * no override in the local directory (KDEHOME)
> 
> The Name= value in the "middle" desktop file would delete the
> currently-loaded translated name, but didn't do so fully (it failed
> to delete the one with bDefault==true, due to the line
> "k.bDefault = false" a few lines before, which wasn't meant to
> affect this). So when reading the Name[locale] in the "middle"
> desktop file afterwards, it said "ok I already have it, do nothing",
> and the english name prevailed.
> The complexity comes from the fact that in such a setup, every key
> is present twice, once with bDefault=false and once with bDefault=true.
> (and then double that, for localized and non-localized).
> 
> After making bDefault=false operate on a copy of the key, a bug was
> uncovered in the if (bDefault) block that was never executed before:
> it should remove the key with bDefault==true, since it already did
> that for bDefault==false (the 4th argument of the KEntryKey ctor).
> 
> Anyway, there's a unittest, so even if nobody ever understands my
> ramblings above, at least it won't regress again.
> 
> 
> Diffs
> -----
> 
>   kdecore/config/kconfigdata.cpp 8f837fb8eec896c1ceb245bc6854cdfba55cce4b 
>   kdecore/tests/kconfigtest.h 3b01c66fd49cda833044dfcb5f2b51c24da7f18b 
>   kdecore/tests/kconfigtest.cpp e5d2e80da0685615a0028ccd7254487664ffc6b0 
> 
> Diff: http://git.reviewboard.kde.org/r/110865/diff/
> 
> 
> Testing
> -------
> 
> Added unittests, ensured existing ones pass.
> 
> Also tested the real-world setup which triggered this bug in the first place (copies of kcmodules in an overlay directory defined in /etc/kde4rc), and translations not appearing in systemsettings when doing that.
> 
> 
> Thanks,
> 
> David Faure
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130618/c1b515eb/attachment.htm>