Re: Internationalizing user interface

On Wed, Oct 23, 2013 at 01:34:14PM +0200, Johannes Hofmann wrote:
> On Wed, Oct 23, 2013 at 11:13:32AM +0200, Petr Pisar wrote:
> > On Wed, Oct 23, 2013 at 10:07:09AM +0200, Johannes Hofmann wrote:
> > > 
> > > I like the idea, but we need man-power to create translations and
> > > keep them up to date.
> > 
> > No, you don't need. The translations are not done by developers, but done
> > by translators.
> 
> Sure, I was just counting translator's man-power too :-)
> 
> > 
> > Developer publishes updated dillo.pot template, translators send back
> > translated message catalogues as <LANG_CODE>.po files.
> > 
> > > Do we have numbers how this affects the memory consumption and
> > > install-size?
> > 
> > See /usr/share/locale/*/LC_MESSAGES in any Linux distribution. Some
> > distributions allow users to select which language to support which saves 
> > theirs disk space too.
> > 
> > The memory overhead is negligeble. Gettext mmaps binary version of translated
> > catalogue and returns static string on each call.
> 
> good
> 
> > 
> > > Do we need a compile-time switch to disable it?
> > 
> > The gettext m4 macros provides --{enable|disable}-nls configure option.
> 
> also good
> 
> > 
> > > How can we keep translation files in sync?
> > > 
> > Register your project at any translations project and use its synchronization
> > system. I like <http://translationproject.org/> which provides developers
> > rsync interface.
> > 
> > Or use just a mailing list to gather updated translations. Like mutt or gnupg
> > does. I do not believe the will such a big traffic with Dillo.
> 
> Ok, so I would suggest we try to get the infrastructure ready and
> use the mailing list initially. Later we can switch to something
> more fancy if necessary.

  IMHO the whole idea is worthwhile.

  It'd be good to test it and coordinate an eventual merge. It
causes large trivial code changes that may difficult the merging
of the floats branch and others, so it should be scheduled with care.

  The other important point is to check how our UI reacts to different
string lenghts because this is not as automatic in FLTK as it was with
GTK.


-- 
  Cheers
  Jorge.-