Long short history…

Transifex plural rules are based on this document. The possible plural rules currently supported are 6, *always* in the respect order:

zero, one, two, few, many, other

The ‘other’ rule is the general exception for anything that doesn’t fit into the other rules. For Japanese, for example, that doesn’t have plural forms, it only uses the ‘other’ rule and nothing else.

According to the document above, Slovenian has 4 plural rules, which are:

one → n mod 100 is 1;
two → n mod 100 is 2;
few → n mod 100 in 3..4;
other → everything else

For the PO file format, the plural equation for the above would be:

(n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || n%100==4 ? 2 : 3)

Which means that for a sl.po with a plural entry, we would have the following mapping:

msgstr[0] → one
msgstr[1] → two
msgstr[2] → few
msgstr[3] → other

Back to the initial issue, for some reason good part of the Slovenian teams across the FOSS world started to prefer to use the following plural equation:

(n%100==1 ? 1 : n%100==2 ? 2 : n%100==3 || n%100==4 ? 3 : 0)

This results in the following swapping of position:

msgstr[0] → other
msgstr[1] → one
msgstr[2] → two
msgstr[3] → few

This, as far as I know, because the ‘zero’ rule, which actually doesn’t exist for the language, just fits as the ‘other’ rule and in this way the ‘one’ and ‘two’ rules would have a synchronized msgstr index (e.g. msgstr[1] → one).

So, dear Slovenian translator, is there any other reason for doing it that I’m not aware of?

Changing that because of the above seems just wrong to me. And I would like to ask a greater audience of people that might be interested on it, before taking any decision on the Transifex side.

So, this week I just came across an issue related to how to setup multiple databases on Django. Reading the documentation I found it quite trivial to setup. After having the databases configured, you can use a Database Router, if you want to automatically route your app models, or use .using(‘db1′) manually on your queries, specifying the wanted database.

As I didn’t want to specify the databases on the queries in my code, so I decided to use the Database Router, which is, by the way, a very nice solution for such a problem. Looking at the example on the Django docs, I realized that the example was only covering the routing of an unique app. Looking further, I also noticed that it was a bit tied with placeholders related to the app and the database names inside the class. Then I asked myself:

Couldn’t it be more generic and reusable for more than one app?

Searching a bit on the Web I couldn’t find anything. Having that in mind, I came with the following code that can be used to specify several apps using different databases. Everything just using a single settings variable and in a very simple way:

from django.conf import settings

class DatabaseAppsRouter(object):
    """
    A router to control all database operations on models for different
    databases.

    In case an app is not set in settings.DATABASE_APPS_MAPPING, the router
    will fallback to the `default` database.

    Settings example:

    DATABASE_APPS_MAPPING = {'app1': 'db1', 'app2': 'db2'}
    """

    def db_for_read(self, model, **hints):
        """"Point all read operations to the specific database."""
        if settings.DATABASE_APPS_MAPPING.has_key(model._meta.app_label):
            return settings.DATABASE_APPS_MAPPING[model._meta.app_label]
        return None

    def db_for_write(self, model, **hints):
        """Point all write operations to the specific database."""
        if settings.DATABASE_APPS_MAPPING.has_key(model._meta.app_label):
            return settings.DATABASE_APPS_MAPPING[model._meta.app_label]
        return None

    def allow_relation(self, obj1, obj2, **hints):
        """Allow any relation between apps that use the same database."""
        db_obj1 = settings.DATABASE_APPS_MAPPING.get(obj1._meta.app_label)
        db_obj2 = settings.DATABASE_APPS_MAPPING.get(obj2._meta.app_label)
        if db_obj1 and db_obj2:
            if db_obj1 == db_obj2:
                return True
            else:
                return False
        return None

    def allow_syncdb(self, db, model):
        """Make sure that apps only appear in the related database."""
        if db in settings.DATABASE_APPS_MAPPING.values():
            return settings.DATABASE_APPS_MAPPING.get(model._meta.app_label) == db
        elif settings.DATABASE_APPS_MAPPING.has_key(model._meta.app_label):
            return False
        return None

I hope the code can self explain what each one of those methods do. And, of course, it’s a generic solution that might be customized as needed.

Here I go to cite a way that can ‘solve’ the URL reversing problem when you are using a Django app that uses some JavaScript and Ajax requests.

Django has a very nice way to resolve URLs based on its name and optionally some args. It uses the regex pattern defined in the related urls.py file of the given app. Example:

from django.core.urlresolvers import reverse

reverse(‘project_detail’, args=['foo'])
‘/projects/p/foo/’

reverse(‘project_detail’, args=['bar'])
‘/projects/p/bar/’

The problem turns when you want to make a Ajax request based on some dynamic data from a form or something. As some URLs sometimes need arguments to be resolved, we can’t always pre-reverse and attach them to the Context, on the Django response.

For the record, I found an alternative here. With it you can take the args from the browser and request through Ajax to Django the resolved URL. It’s pretty cool, but I think it was a bit expensive to multiply by 2 the number of requests to the server.

It made me think on another approach, where I would pre-fill in the Context response of Django, the URL already resolved, but with named args like, %(project)s, for the required arguments. I ended up with this:

from django.core.urlresolvers import get_resolver

def get_url_pattern(urlname):
“”"
Return pattern for an URL based on its name.

>>> get_url_pattern(‘project_deails’)
u’/projects/p/%(project_slug)s/’

“”"
return ‘/%s’ % get_resolver(None).reverse_dict.get(urlname)[0][0][0]

As you can notice, passing an URL name to that function will give you the resolved URL with named args. I’m not really aware about corner cases, so feel free to give any comment on it.

Once you have the URL as a string with named args, you can use this JQuery plugin, to resolve the named args using only JavaScript in the client side.

… and that’s it!

$ sudo yum install postgresql-server python-psycopg2

$ sudo service postgresql initdb
Initializing database: [ OK ]

$ sudo service postgresql start
Starting postgresql service: [ OK ]

$ sudo su – postgres

-bash-4.0$ psql

postgres=# CREATE USER transifex WITH PASSWORD ‘transifex’;
CREATE ROLE

postgres=# CREATE DATABASE transifex OWNER transifex;
CREATE DATABASE

postgres=# \q

-bash-4.0$ exit

$ sudo vim /var/lib/pgsql/data/pg_hba.conf

# “local” is for Unix domain socket connections only
local transifex transifex password # Add this line
local all all ident

$ sudo service postgresql restart

$ psql transifex transifex
Password for user transifex:
psql (8.4.1)
Type “help” for help.

transifex=>

transifex=> \q

# Bellow it assumes the Tx code is under ~/workspace/mainline/ and
# all the dependencies are installed. http://docs.transifex.org/intro/install.html

$ cd workspace/mainline/transifex/

$ vim settings/21-engines.conf

# Database configuration
DATABASE_ENGINE = ‘postgresql_psycopg2′
DATABASE_NAME = ‘transifex’
DATABASE_USER = ‘transifex’
DATABASE_PASSWORD = ‘transifex’

$ ./manage.py syncdb

$ ./manage.py migrate codebases # It shouldn’t be necessary :/

$ ./manage.py migrate

$ ./manage.py loaddata txcommon/fixtures/*

$ ./manage.py runserver 8080

That’s it!

That was a cool stuff. Here is a code example of an admin.py