[Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
gettext[1] supports both the GNU gettext catalog API and higher level, class-based API that may be more appropriate for Python files. This commit changes the code to use the higher level, class-based API to return Unicode objects instead 8bits strings as it was. This allows us to have the code consistent throughout all our activities. Signed-off-by: Manuel Kaufmann --- bin/sugar-activity | 7 --- src/sugar3/activity/activity.py| 5 +++-- src/sugar3/activity/widgets.py | 4 +++- src/sugar3/graphics/alert.py | 4 +++- src/sugar3/graphics/colorbutton.py | 4 +++- src/sugar3/util.py | 11 ++- 6 files changed, 22 insertions(+), 13 deletions(-) diff --git a/bin/sugar-activity b/bin/sugar-activity index 5aef1ae..2bc82b0 100644 --- a/bin/sugar-activity +++ b/bin/sugar-activity @@ -101,9 +101,10 @@ def main(): # must be done early, some activities set translations globally, SL #3654 locale_path = i18n.get_locale_path(bundle.get_bundle_id()) -gettext.bindtextdomain(bundle.get_bundle_id(), locale_path) -gettext.bindtextdomain('sugar-toolkit', sugar3.locale_path) -gettext.textdomain(bundle.get_bundle_id()) + +# Install the actual Activity Domain to be able to use _() to +# translate strings and get Unicode objects +gettext.install(bundle.get_bundle_id(), locale_path, unicode=1) splitted_module = args[0].rsplit('.', 1) module_name = splitted_module[0] diff --git a/src/sugar3/activity/activity.py b/src/sugar3/activity/activity.py index 8386c1e..b340853 100644 --- a/src/sugar3/activity/activity.py +++ b/src/sugar3/activity/activity.py @@ -73,6 +73,7 @@ from telepathy.interfaces import CHANNEL, \ from telepathy.constants import CONNECTION_HANDLE_TYPE_CONTACT from telepathy.constants import CONNECTION_HANDLE_TYPE_ROOM +import sugar3 from sugar3 import util from sugar3.presence import presenceservice from sugar3.activity.activityservice import ActivityService @@ -84,8 +85,8 @@ from sugar3.datastore import datastore from sugar3.session import XSMPClient from sugar3 import wm - -_ = lambda msg: gettext.dgettext('sugar-toolkit', msg) +t = gettext.translation('sugar-toolkit', sugar3.locale_path) +_ = t.ugettext SCOPE_PRIVATE = 'private' SCOPE_INVITE_ONLY = 'invite' # shouldn't be shown in UI, it's implicit diff --git a/src/sugar3/activity/widgets.py b/src/sugar3/activity/widgets.py index c4015ce..5865cd3 100644 --- a/src/sugar3/activity/widgets.py +++ b/src/sugar3/activity/widgets.py @@ -23,6 +23,7 @@ import gettext from gi.repository import GConf import logging +import sugar3 from sugar3.graphics.toolbutton import ToolButton from sugar3.graphics.toolbarbox import ToolbarButton from sugar3.graphics.radiopalette import RadioPalette, RadioMenuButton @@ -34,7 +35,8 @@ from sugar3.bundle.activitybundle import ActivityBundle from sugar3.graphics import style -_ = lambda msg: gettext.dgettext('sugar-toolkit', msg) +t = gettext.translation('sugar-toolkit', sugar3.locale_path) +_ = t.ugettext def _create_activity_icon(metadata): diff --git a/src/sugar3/graphics/alert.py b/src/sugar3/graphics/alert.py index 16392cd..600d7fc 100644 --- a/src/sugar3/graphics/alert.py +++ b/src/sugar3/graphics/alert.py @@ -52,11 +52,13 @@ from gi.repository import GObject from gi.repository import GLib import math +import sugar3 from sugar3.graphics import style from sugar3.graphics.icon import Icon -_ = lambda msg: gettext.dgettext('sugar-toolkit', msg) +t = gettext.translation('sugar-toolkit', sugar3.locale_path) +_ = t.ugettext class Alert(Gtk.EventBox): diff --git a/src/sugar3/graphics/colorbutton.py b/src/sugar3/graphics/colorbutton.py index 95d023a..56f668c 100644 --- a/src/sugar3/graphics/colorbutton.py +++ b/src/sugar3/graphics/colorbutton.py @@ -24,12 +24,14 @@ from gi.repository import GObject import struct import logging +import sugar3 from sugar3.graphics import style from sugar3.graphics.icon import Icon from sugar3.graphics.palette import Palette, ToolInvoker, WidgetInvoker -_ = lambda msg: gettext.dgettext('sugar-toolkit', msg) +t = gettext.translation('sugar-toolkit', sugar3.locale_path) +_ = t.ugettext def get_svg_color_string(color): diff --git a/src/sugar3/util.py b/src/sugar3/util.py index baec3b1..923dc72 100644 --- a/src/sugar3/util.py +++ b/src/sugar3/util.py @@ -30,8 +30,10 @@ import tempfile import logging import atexit +import sugar3 -_ = lambda msg: gettext.dgettext('sugar-toolkit', msg) +t = gettext.translation('sugar-toolkit', sugar3.locale_path) +_ = t.ugettext def printable_hash(in_hash): @@ -270,10 +272,9 @@ def timestamp_to_elapsed_string(timestamp, max_levels=2): if key in _i18n_timestamps_cache: time_period += _i18n_timestamps_cache[key] else: -tmp = gettext.dngettext('sugar-toolkit', -name_singular, -
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
Humitos, We need help form more experienced people here to do the review. Can you explain the problem you are trying to solve and why you think this is the right solution? Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 3:49 PM, Gonzalo Odiard wrote: > Can you explain the problem you are trying to solve and > why you think this is the right solution? I sent an email yesterday commenting what the problem is and what the best solution is. Here is the thread: * http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038928.html Broadly speaking, the issue is related with "merging Unicode string with 8bits ones" and this convey many problems that are difficult to find out and solve. In Python, is highly recommended to use Unicode throughout the source code and encode the string when it is necessary. For example, when you want to save some text into a file or send data through internet (via HTTP POST). With this patch there is no need to change the source code of all the activities, they should work as they are. But, we can omit the import of gettext as _ because this patch installs it as a builtin function[1]: from gettext import gettext as _ For this reason, we can omit this line in new Activities. Is it clearer now? Thanks, [1] http://docs.python.org/library/gettext.html#gettext.install -- Kaufmann Manuel Blog: http://humitos.wordpress.com/ Porfolio: http://fotos.mkaufmann.com.ar/ PyAr: http://www.python.com.ar/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 1:15 PM, Manuel Kaufmann wrote: > Broadly speaking, the issue is related with "merging Unicode string > with 8bits ones" and this convey many problems that are difficult to > find out and solve. In Python, is highly recommended to use Unicode > throughout the source code Personally, I'd say that recommending universal use of unicode in Python 2 is questionable. > With this patch there is no need to change the source code of all the > activities, they should work as they are. But, we can omit the import > of gettext as _ because this patch installs it as a builtin > function[1]: > > from gettext import gettext as _ So _ will suddenly change from returning a string to a unicode for all activities? That is likely to break several things, for the same reasons that we recently saw in another thread: why doesn't pygi return unicode strings for GtkEntry.get_text() and so on? The unicode mess is sorted in Python 3; it may be better to invest effort in moving that direction instead. (after a quick glance at the thread you linked to, I'm not sure what the actual problem is). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 6:55 PM, Daniel Drake wrote: > So _ will suddenly change from returning a string to a unicode for all > activities? Yes. Actually, this patch is only for the activities that are being ported to Gtk3 (because it affects just to sugar-toolkit-gtk3) and it's a good point to start handling strings as it should be (Unicode) :) > That is likely to break several things, for the same > reasons that we recently saw in another thread: why doesn't pygi > return unicode strings for GtkEntry.get_text() and so on? Can you point me out to that thread? I didn't read it. > The unicode mess is sorted in Python 3; it may be better to invest > effort in moving that direction instead. (after a quick glance at the > thread you linked to, I'm not sure what the actual problem is). How can I help you to make it clearer? -- Kaufmann Manuel Blog: http://humitos.wordpress.com/ Porfolio: http://fotos.mkaufmann.com.ar/ PyAr: http://www.python.com.ar/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 4:19 PM, Manuel Kaufmann wrote: >> That is likely to break several things, for the same >> reasons that we recently saw in another thread: why doesn't pygi >> return unicode strings for GtkEntry.get_text() and so on? > > Can you point me out to that thread? I didn't read it. http://bugs.sugarlabs.org/ticket/2830 > How can I help you to make it clearer? Show us an activity that fails because of this and give some details/explanation. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
2012/8/14 Manuel Kaufmann : > On Tue, Aug 14, 2012 at 3:49 PM, Gonzalo Odiard wrote: >> Can you explain the problem you are trying to solve and >> why you think this is the right solution? > > I sent an email yesterday commenting what the problem is and what the > best solution is. Here is the thread: > > * http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038928.html -1 I already explained my position at that thread, and my namesake dsd is also disagreeing as I can see. > With this patch there is no need to change the source code of all the > activities, they should work as they are. But, we can omit the import > of gettext as _ because this patch installs it as a builtin > function[1]: > > from gettext import gettext as _ > > For this reason, we can omit this line in new Activities. > +1 Does the old import generate a conflict or the developers must use a conditional for backward compatibility? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 7:35 PM, Daniel Drake wrote: > Show us an activity that fails because of this and give some > details/explanation. I've already explain this on the other thread (I linked it in this one too), it talks about Typing Turtle and the "Congratulation.." string but don't worry. There is another activity that has this problem as well: Get Books. This commit shows the "hack" that we have to use to combine 8bits and Unicode strings: * http://git.sugarlabs.org/get-books/mainline/commit/165ce7c28a51ec016f9b4dcbb2dd27203539d186 I'm sure that is not the correct way to handle this problem and I'm 100% sure this should be solved using Unicode throughout the code but maybe I'm wrong in the way that I'm proposing. I'm not a Sugar expert. The REAL problem is mixing of Unicode with 8bits strings. We have to decide to use ONLY one of them and there are many reasons for use Unicode (as I pointed you out on the other thread). We MUSTN'T mix them. Some examples with weird results: * Unicode + Unicode -> No problem >>> u'Tengo un ' + u'camión' u'Tengo un cami\xf3n' * 8bits (utf8) + 8bits (utf8) -> No problem >>> 'Tengo un ' + 'camión' 'Tengo un cami\xc3\xb3n' * 8bits (utf8) + Unicode -> No problem >>> 'Tengo un ' + u'camión' u'Tengo un cami\xf3n' * Unicode + 8bits (utf8) -> CRASH !! >>> u'Tengo un ' + 'camión' Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4: ordinal not in range(128) So, Unicode at the left side of the operator crash... Is that an expected behaviour? Why it doesn't crash at the right side too? Should I check every strings on my code? We need an unique way to handle our strings and Unicode comes to my mind everytime :) . Python's gettext module and Unicode's documentation recommend that, why are we going to go in the opposite direction? Cheers, -- Kaufmann Manuel Blog: http://humitos.wordpress.com/ Porfolio: http://fotos.mkaufmann.com.ar/ PyAr: http://www.python.com.ar/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel