October 2013 - Dillo-dev - lists.mailman3.com

socks proxy possible?

by rudolf.sykora＠gmail.com

Hello, I wanted to use dillo with a socks proxy (using ssh -D portnumber), however, I was not successful. ( I did export http_proxy=127.0.0.1:portnumber and then ran dillo, but then it sais 'connecting' for any url given and nothing happens. ) Is this somehow possible? Thank you! Ruda

Oct. 31, 2013

Internationalizing user interface

by jcid＠dillo.org

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.-

Oct. 23, 2013

Internationalizing user interface

by johannes.hofmann＠gmx.de

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

Oct. 23, 2013

Internationalizing user interface

by petr.pisar＠atlas.cz

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

Oct. 23, 2013

Internationalizing user interface

by johannes.hofmann＠gmx.de

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

Oct. 23, 2013

Internationalizing user interface

by petr.pisar＠atlas.cz

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

Oct. 23, 2013

Internationalizing user interface

by corvid＠dillo.org

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.

Oct. 22, 2013

Internationalizing user interface

by petr.pisar＠atlas.cz

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

Oct. 21, 2013

Image backgrounds

by sgeerken＠dillo.org

Hi! At <http://flpsed.org/hgweb/dillo_background_image>, you'll find a version of dillo which supports background images. 'Background- attachement' is missing, which I'll postpone, but the rest is nearly complete. I'll soon resume my work on floats. Sebastian

Oct. 14, 2013