KConfigGroup and entryMap

[Albert Astals Cid]

A Dijous 27 Desembre 2007, Thomas Braxton va escriure:
> On Dec 27, 2007 5:45 AM, Mauricio Piacentini <piacentini at kde.org> wrote:
> > Apparently there was a recent change in behavior for
> > KConfigGroup->entryMap(). This broke translation of theme files for
> > games, you can see it in KMines for example. What happens in short is
> > the in kgametheme.cpp we had something like:
> >
> >      KConfigGroup group = themeconfig.group(d->themeGroup);
> >      d->themeproperties = group.entryMap();
> >
> > And the returned entryMap would have the entries in the default, non
> > localized format. If we do:
> >
> >      KConfigGroup group = themeconfig.group(d->themeGroup);
> >      kDebug(11000) << "Name map is" << group.readEntry("Name");
> >
> > Then Name is returned in the correct, localized format.
> >
> > So the question is: how do we deal with this? One obvious solution now
> > is to maybe loop through all the keys in the returned entryMap (or use
> > KConfigGroup->keyList(), which is also untranslated right now), and
> > extract and store the localized versions for the values. HOWEVER, this
> > might break again in the future, if entryMap() or keyList() is changed
> > to return localized data. It is a matter of how the API is supposed to
> > work. To the KConfig guys:
> >
> > In the case above, what is the correct behavior? Should entryMap or
> > keyList return translated data, or not? Can we rely on this for the
> > future?
>
> entryMap() will/should return a localized entry if there is one.

There there is a bug as it's returning the non localized one.

Albert

> Usually if the entry _is_ localized the localized version is the one
> wanted. If you need the untranslated entry you should use
> KConfigGroup::readEntryUntranslated().
>
> keyList() simply returns the names of the entries, so it shouldn't be
> able to return anything localized.
>
> > I am not sure at which point the behavior of KConfig was changed, but
> > right now my main concern is to define the behavior of the API, instead
> > of coding a workaround in libkdegames that might break again in the
> > future.
> >
> > Regards,
> > Mauricio Piacentini