Internationalizing user interface

[Petr Pisar]

Hello,

I notice Dillo is in English only, so I prepared an example how to
internationalize the code using gettext.

The initial patch is quite huge due to standard m4 macros supporting the
gettext configuration:

ABOUT-NLS | 1282 ++++++++++++++++++++++++++++++++++++++++++++++++
Makefile.am | 6 +-
config.rpath | 690 +++++++++++++++++++++++++
configure.ac | 3 +-
m4/gettext.m4 | 401 +++++++++++++++
m4/iconv.m4 | 268 ++++++++++
m4/lib-ld.m4 | 119 ++++
m4/lib-link.m4 | 777 +++++++++++++++++++++++++++++
m4/lib-prefix.m4 | 224 ++++++++
m4/nls.m4 | 32 +
m4/po.m4 | 452 ++++++++++++++++
m4/progtest.m4 | 91 +++
po/Makefile.in.in | 453 ++++++++++++++++
po/Makevars | 53 +
po/POTFILES.in | 4 +
po/Rules-quot | 47 +
po/boldquot.sed | 10 +
po/cs.po | 163 ++++++
po/en-Q/***@public.gmane.org | 25 +
po/en-***@public.gmane.org | 22 +
po/insert-header.sin | 23 +
po/quot.sed | 6 +
po/remove-potcdate.sin | 19 +
src/Makefile.am | 2 +
src/dillo.cc | 64 +-
src/gettext.h | 287 ++++++++++
src/menu.cc | 13 +-
src/msg.h | 3 +-
src/nls.h | 17 +
src/ui.cc | 7 +-
30 files changed, 5524 insertions(+), 39 deletions(-)

I don't know what everything you want to track in the hg.

The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get
installed through ./autogen.sh by calling gettextize --force --no-changelog.

My proof of concept shows internationalized and the localized into Czech
language the `dillo --help' usage and the `File' menu in the GUI.

Should I send the (possibly compressed) patch to this mailing list?

If you liked the patch, I'm willing to walk through all the sources and mark
all the stringing suitable for translation.

-- Petr

[corvid]

Post by Petr Pisar
I notice Dillo is in English only, so I prepared an example how to
internationalize the code using gettext.
The initial patch is quite huge due to standard m4 macros supporting the

[snip]

Post by Petr Pisar
30 files changed, 5524 insertions(+), 39 deletions(-)
I don't know what everything you want to track in the hg.
The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get
installed through ./autogen.sh by calling gettextize --force --no-changelog.
My proof of concept shows internationalized and the localized into Czech
language the `dillo --help' usage and the `File' menu in the GUI.
Should I send the (possibly compressed) patch to this mailing list?
If you liked the patch, I'm willing to walk through all the sources and mark
all the stringing suitable for translation.

I looked in the archive to refresh my memory on where everyone stood on
gettext. Jorge felt positively toward it in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008658.html
I was curious about it and tried a small experiment in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008685.html
And no one else expressed an opinion. So that's a good sign, anyway.

The convention here for large patches is to put them somewhere else and
give the url.

[Petr Pisar]

Post by corvid

Post by Petr Pisar
I notice Dillo is in English only, so I prepared an example how to
internationalize the code using gettext.
The initial patch is quite huge due to standard m4 macros supporting the

[snip]

Post by Petr Pisar
30 files changed, 5524 insertions(+), 39 deletions(-)
I don't know what everything you want to track in the hg.
The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get
installed through ./autogen.sh by calling gettextize --force --no-changelog.
My proof of concept shows internationalized and the localized into Czech
language the `dillo --help' usage and the `File' menu in the GUI.
Should I send the (possibly compressed) patch to this mailing list?
If you liked the patch, I'm willing to walk through all the sources and mark
all the stringing suitable for translation.

I looked in the archive to refresh my memory on where everyone stood on
gettext. Jorge felt positively toward it in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008658.html
I was curious about it and tried a small experiment in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008685.html
And no one else expressed an opinion. So that's a good sign, anyway.
The convention here for large patches is to put them somewhere else and
give the url.

Here it is: <http://xpisar.wz.cz/dillo/dillo-i18n.diff>.

-- Petr

[Johannes Hofmann]

Post by corvid

Post by Petr Pisar
I notice Dillo is in English only, so I prepared an example how to
internationalize the code using gettext.
The initial patch is quite huge due to standard m4 macros supporting the

[snip]

Post by Petr Pisar
30 files changed, 5524 insertions(+), 39 deletions(-)
I don't know what everything you want to track in the hg.
The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get
installed through ./autogen.sh by calling gettextize --force --no-changelog.
My proof of concept shows internationalized and the localized into Czech
language the `dillo --help' usage and the `File' menu in the GUI.
Should I send the (possibly compressed) patch to this mailing list?
If you liked the patch, I'm willing to walk through all the sources and mark
all the stringing suitable for translation.

I looked in the archive to refresh my memory on where everyone stood on
gettext. Jorge felt positively toward it in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008658.html
I was curious about it and tried a small experiment in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008685.html
And no one else expressed an opinion. So that's a good sign, anyway.

I like the idea, but we need man-power to create translations and
keep them up to date.
Do we have numbers how this affects the memory consumption and
install-size?
Do we need a compile-time switch to disable it?
How can we keep translation files in sync?

Cheers,
Johannes

[Petr Pisar]

Post by Johannes Hofmann
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.

Developer publishes updated dillo.pot template, translators send back
translated message catalogues as <LANG_CODE>.po files.

Post by Johannes Hofmann
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.

Post by Johannes Hofmann
Do we need a compile-time switch to disable it?

The gettext m4 macros provides --{enable|disable}-nls configure option.

Post by Johannes Hofmann
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.

-- Petr

[Johannes Hofmann]

Post by Petr Pisar

Post by Johannes Hofmann
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 :-)

Post by Petr Pisar
Developer publishes updated dillo.pot template, translators send back
translated message catalogues as <LANG_CODE>.po files.

Post by Johannes Hofmann
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

Post by Petr Pisar

Post by Johannes Hofmann
Do we need a compile-time switch to disable it?

The gettext m4 macros provides --{enable|disable}-nls configure option.

also good

Post by Petr Pisar

Post by Johannes Hofmann
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.

Johannes

[Jorge Arellano Cid]

Post by Johannes Hofmann

Post by Petr Pisar

Post by Johannes Hofmann
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 :-)

Post by Petr Pisar
Developer publishes updated dillo.pot template, translators send back
translated message catalogues as <LANG_CODE>.po files.

Post by Johannes Hofmann
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

Post by Petr Pisar

Post by Johannes Hofmann
Do we need a compile-time switch to disable it?

The gettext m4 macros provides --{enable|disable}-nls configure option.

also good

Post by Petr Pisar

Post by Johannes Hofmann
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.