[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 humi...@gmail.com
---
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
On Tue, Aug 14, 2012 at 1:15 PM, Manuel Kaufmann humi...@gmail.com 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 d...@laptop.org 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 humi...@gmail.com 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 humi...@gmail.com: On Tue, Aug 14, 2012 at 3:49 PM, Gonzalo Odiard gonz...@laptop.org 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 d...@laptop.org 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 stdin, line 1, in module 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
