[glideplan_swproj] Re: translations, new interfaces for settings

  • From: Cestmir Houska <czestmyr@xxxxxxxxx>
  • To: glideplan_swproj@xxxxxxxxxxxxx
  • Date: Wed, 16 May 2012 11:28:12 +0200

Yeah, both ideas are good and I agree with them.

As for 1), I'd rather keep the settings interface as is and add a
method translateSettings(QString key, QString newDescription).


On Wed, May 16, 2012 at 1:42 AM, Kuba Marek <blue.cube@xxxxxxxxx> wrote:
> Hi,
> I'm working on the translations and i've found some problems with
> our interface with settings.
> Here are some suggestions what to do with it.
> The problem is that we will need to be able to update the translations
> of everything in the code, including settings
> 1) we could remove descriptions from addSetting and add a new
> method
> void setSettingDescription(QString key, QString description) that would
> be called after addSetting and every time the traslation
> changes.
> Maybe we could keep addSetting the way it is, but it would lead to
> duplication of the strings -- one place would be where the settings are
> created and another where they're updated. Also keeping it at both
> places creates a (weak) circular dependency -- translations need a
> setting to load a correct language and settings need a language to
> translate the description.
> 2) plugins need to be translated too. This means adding a method to
> plugin base that sets all the translated strings again.
> Then there are two slightly unrelated changes:
> Using the settings in plugins is pretty hard ... interface should get a
> method like this:
> template <typename T> const T& getSetting(const QString key&) const;
> to keep us from shuffling pointers to SettingInterface around
> QVariants are complicated to use and add a room for errors.
> SettingInterface should be a template and return directly the
> value. This also goes for addSetting.
> What do you think?
> Kuba

To visit archive or unsubscribe, follow:

Other related posts: