- Dillo-dev - lists.mailman3.com

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

patch: binding to add bookmark

by jcid＠dillo.org

On Mon, Sep 16, 2013 at 06:20:38PM +0200, corvid wrote: > Another simple one from the bug tracker. I don't use bookmarks heavily > enough to have much need for this, but I can see that it could be > convenient. > It looks like the user wants the feature as a workaround, so he can quickly bookmark the tabs he has open, with a view to recover them later. See BUG #1136, #1137 and #1139. IMHO, it would be great to contact the submitter to understand the real problem (or use case) he has, and try to aim directly at it. -- Cheers Jorge.-

Sept. 20, 2013

patch: binding to add bookmark

by corvid＠dillo.org

Another simple one from the bug tracker. I don't use bookmarks heavily enough to have much need for this, but I can see that it could be convenient.

Sept. 16, 2013

patch: show_ui_tooltip

by jcid＠dillo.org

On Fri, Sep 13, 2013 at 09:08:23AM +0200, Johannes Hofmann wrote: > On Thu, Sep 12, 2013 at 04:14:04PM +0200, Sebastian Geerken wrote: > > On Mi, Sep 11, 2013, Johannes Hofmann wrote: > > > On Wed, Sep 11, 2013 at 05:34:06PM +0200, corvid wrote: > > > > Someone in the bug tracker was asking about turning off the ui's tooltips. > > > > > > What about using the existing prefs.show_tooltip variable for both > > > types of tooltips? I would guess that someone either likes / wants > > > tooltips or not independent of whether it's for the UI or the page > > > contents. > > > > Tooltips are useful to get an idea what an (simple to recognize, but > > otherwise per se unrelated to the meaning) icon is for. (At least for > > me, the text "Reload" makes much more sense than two bent arrows > > pointing to each other's tail). > > > > After some while, a user remembers the icon, so she does not need the > > text anymore; and I guess that icons are faster to realise than text. > > On the other hand, this argument does not count for (new) web pages, > > where the meaning of the icons is not yet known. > > > > For this reason, my opinion is that a distinction is not completely > > pointless. > > Ok, I'm fine with two separate variables too. +1 -- Cheers Jorge.-

Sept. 13, 2013

patch: show_ui_tooltip

by johannes.hofmann＠gmx.de

On Thu, Sep 12, 2013 at 04:14:04PM +0200, Sebastian Geerken wrote: > On Mi, Sep 11, 2013, Johannes Hofmann wrote: > > On Wed, Sep 11, 2013 at 05:34:06PM +0200, corvid wrote: > > > Someone in the bug tracker was asking about turning off the ui's tooltips. > > > > What about using the existing prefs.show_tooltip variable for both > > types of tooltips? I would guess that someone either likes / wants > > tooltips or not independent of whether it's for the UI or the page > > contents. > > Tooltips are useful to get an idea what an (simple to recognize, but > otherwise per se unrelated to the meaning) icon is for. (At least for > me, the text "Reload" makes much more sense than two bent arrows > pointing to each other's tail). > > After some while, a user remembers the icon, so she does not need the > text anymore; and I guess that icons are faster to realise than text. > On the other hand, this argument does not count for (new) web pages, > where the meaning of the icons is not yet known. > > For this reason, my opinion is that a distinction is not completely > pointless. Ok, I'm fine with two separate variables too. Johannes

Sept. 13, 2013