g================================== 20130316 (Saturday, 16 March 2013) ==================================

Ein letztes Wort vor dem Release…

Das oben erwähnte Wort “Probezeit” ist ja neu, also muss ich mich nochmal um Übersetzung kümmern.

Die Befehle dazu sind momentan noch in der Makefile, es sind ungefähr die letzten, die ich noch nicht durch fabric ersetzt habe.

Aber wenn ich mich schon da dran setze, will ich auch Nägel mit Köpfen zu machen und schau ich mir zunächst einmal python-babel etwas genauer an.

Weil ich ja auch das Problem mit dem selbstgewurstelten Message extraction aus der linoweb.js habe.

Nach 2 Seiten weiß ich: jawohl, ich will jetzt sofort auf Babel umsteigen. Und nach der dritten Seite weiß ich: wenn ich schon vor einigen Tagen umgestiegen wäre, hätte ich mir einige Stunden Arbeit ersparen können. Da steht doch tatsächlich genau das dokumentiert, was ich vor ein paar Tagen (2013-03-11) programmiert habe:

>>> from lino import startup
>>> startup('lino_book.projects.docs.settings.demo')
>>> from lino.api.doctest import *

>>> import datetime
>>> from babel.dates import format_date
>>> d = datetime.date(2013,3,15)
>>> format_date(d, format='full', locale='de')
'Freitag, 15. März 2013'
>>> format_date(d, format='full', locale='en_US')
'Friday, March 15, 2013'
>>> format_date(d, format='full', locale='en_GB')
'Friday, 15 March 2013'

I felt a bit ashamed for having reinvented a wheel which is obviously rather well known…

I found some relief when I saw that it is a common problem. Babel uses “en_US” to designate Americal English while Django uses “en-us”.

>>> format_date(d, format='full', locale='en-us')
Traceback (most recent call last):
...
ValueError: expected only letters, got 'en-us'

That’s a historic trace of the fact that people are constantly reinventing wheels.

Fortunately I’m obviously not the first who had this problem, and Django already has a solution, the to_locale() function:

>>> from django.utils.translation import to_locale
>>> format_date(d, format='full', locale=to_locale('en-us'))
'Friday, March 15, 2013'
>>> to_locale('de')
'de'
>>> to_locale('de-be')
'de_BE'

After these experiments (BTW this blog page is being doctested while I’m writing it) I start to feel ready for another invisible but important change: support for locale names instead of simple language names in languages.

To test the new feature I wrote a tutorial https://www.lino-framework.org/tutorials/de_BE/index.html.

Installing mysql-python in a virtualenv on Debian Squeeze

Release on The Lino framework, including a move to virtualenv.

pip install MySQL-python didn’t work

This was a bit tricky: had to do:

$ aptitude install libmysqlclient-dev python-dev

There wer still several little bugs.

Printing is currently broken on The Lino framework. For some reason

Deploying data files

To continue where I stopped 2013-03-14: if was indeed quite close to the result. It was enough to just move the media directory one level down to lino (again). And of course include_package_data = True in my setup.py.

And one more detail: to access the files to be served at media/lino, I had replaced the line:

setup_media_link('lino',source=join(dirname(lino.__file__),'media'))

by:

from pkg_resources import Requirement, resource_filename
setup_media_link('lino',source=resource_filename(Requirement.parse("lino"),"lino/media"))

But in fact I can keep both possibilities: if Lino is not installed using pip, fall back to using the source tree:

from pkg_resources import Requirement, resource_filename, DistributionNotFound

try:
    setup_media_link('lino',source=resource_filename(Requirement.parse("lino"),"lino/media"))
except DistributionNotFound as e:
    setup_media_link('lino',source=join(dirname(lino.__file__),'media'))