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 at boldquot.header | 25 + po/en at quot.header | 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
Petr wrote:
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:
[snip]
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.
On Wed, Oct 23, 2013 at 12:10:44AM +0200, corvid wrote:
Petr wrote:
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:
[snip]
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
On Wed, Oct 23, 2013 at 12:10:44AM +0200, corvid wrote:
Petr wrote:
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:
[snip]
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
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. 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.
Do we need a compile-time switch to disable it?
The gettext m4 macros provides --{enable|disable}-nls configure option.
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
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. Johannes
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.-
participants (4)
-
corvid＠dillo.org -
jcid＠dillo.org -
johannes.hofmann＠gmx.de -
petr.pisar＠atlas.cz