Created attachment 140490 [details] [review]
Fix dash usage

Thank you very much for the effort - changes committed to git master!

Hey Philip! We just picked up bug 618500.
Do you by any chance know any issues with gettext and em/en-dashes?

Hmm, I also wonder if maybe em-dashing and fancy-quoting could be left to localised version (en_US, en_GB).

(In reply to comment #3)
> Hey Philip! We just picked up bug 618500.
> Do you by any chance know any issues with gettext and em/en-dashes?

That's worrying. I haven't heard of any issues before, but there aren't many GNOME modules using Unicode which are written in Python.

From a quick search[1], it looks like you need to specify unicode=1 if you're using gettext.install(), or perhaps bind _() to gettext.ugettext() rather than gettext.gettext(). Failing that, forcing the strings to be Unicode by prefixing them with 'u' (e.g. u"this is a string") might help. I don't really know enough Python to be able to say what's wrong.

(In reply to comment #4)
> Hmm, I also wonder if maybe em-dashing and fancy-quoting could be left to
> localised version (en_US, en_GB).

Ideally not, since in GNOME the C locale is defined to be American English. Hopefully this can be fixed without resorting to moving the Unicode characters to separate locales.

(In reply to comment #5)
> From a quick search[1], …

Would be useful if I actually gave the reference:
http://docs.python.org/library/gettext.html

Actually one should always prefix non-ASCII strings with "u" as otherwise these are treated like a bunch of random bytes. It's entirely possible that the string extractor treats the strings as UTF-8 (it pays no attention to the python prefix) while python asks the compiled localization for something completely different ("give me the translation for that bunch of random bytes") and gets nothing back (as there are no exact matches).

Oh i did try out the usual suspects. Also some of the strings are in the glade files.
Unicode is being specified on install
http://git.gnome.org/browse/hamster-applet/tree/src/hamster/configuration.py#n59

Prefixing string as unicode also does not do the trick.

(In reply to comment #8)
> Oh i did try out the usual suspects. Also some of the strings are in the glade
> files.
> Unicode is being specified on install
> http://git.gnome.org/browse/hamster-applet/tree/src/hamster/configuration.py#n59
> 
> Prefixing string as unicode also does not do the trick.

I have no other ideas, since I'm rubbish at Python. I guess you should either find a Python Unicode expert or revert my patch ASAP.

I don't understand why it's not working, given that everything I've read in the Python documentation suggests that gettext.ugettext(u'some Unicode string') should be absolutely fine.

i consider the bug minor, just was hoping that you might maybe know something more :)
will give it another go some point later. right now it kind of feels boring :)

(In reply to comment #10)
> i consider the bug minor, just was hoping that you might maybe know something
> more :)

Several window titles being untranslated is not a minor bug!

then how comes that we have received just one bug report since they were brought in last year?
of course it's a minor!
don't panic - we will fix it :)

(In reply to comment #10)
> i consider the bug minor, just was hoping that you might maybe know something
> more :)
> will give it another go some point later. right now it kind of feels boring :)

I just tested this in Totem, and Totem's Python plugins have the same problem. However, making the strings into Unicode objects and adding a file encoding line at the top of the file fixed it. It might be because Totem sets up gettext for Python in a different way? Totem uses:

import gettext
gettext.textdomain("totem")

D_ = gettext.dgettext
_ = gettext.gettext

my_translated_string = _(u'foobar…with Unicode')

This seems to be in contradiction with the advice that I read about which says to use gettext.ugettext(). Hum.

Then again, Totem does have the following in the C loader for Python plugins, so it does effectively call the gettext.install() method for each Python plugin it loads:

/* i18n support */
gettext = PyImport_ImportModule ("gettext");
if (gettext == NULL) {
	g_warning ("Could not import gettext");
	PyErr_Print();
	return;
}

mdict = PyModule_GetDict (gettext);
install = PyDict_GetItemString (mdict, "install");
gettext_args = Py_BuildValue ("ss", GETTEXT_PACKAGE, GNOMELOCALEDIR);
PyObject_CallObject (install, gettext_args);
Py_DECREF (gettext_args);

ok, finally solved it!
a rather nasty gotcha - the locale had been installed properly, but translation in my po file was marked as fuzzy (that is having "#, fuzzy" before the translation). Strangely that lead to not translating.
Also the strings had to be cast as unicode.

Thanks for your input Philip!