When adding a migration on master, I discovered that the new-style
migrations were strongly out of sync; Django wanted to create new
migrations for almost every app. That was surprising given that no model
changes were made since building that set of migrations.

The issue is that they were built with Django 1.7 RC2, and we've since
switchted to RC3. If I'd have to guess, I'd say the following issue is
responsible for it:
2da20379c0

As beta 1 is only a day old and it doesn't cause major headaches, it was
decided that it's easiest to release a new set of migrations. And pray
to the gods of Python that we won't have a similar situation again
before the Django migrations framework stabilises.

Native migrations created with Python 2 differ from ones created with
Python 3. More importantly, they failed when used in Python 3, but not
vice versa. This is caused by field names being marked as byte strings
when using Python 2.

This rewrites the native migrations, which probably isn't a bad thing
either, because they were created with a pre-RC2 version of Django, and
Django 1.7 has since seen a few more migration-related fixes.

It's likely Django now does the correct thing and generates Python 2 and
3 compatible migrations under both versions of Python.

This commit adds the python_2_unicode_compatible decorator to all models
that define a text representation. Furthermore, it adds a test to ensure
that we never forget to do that.

It is explained in details in the Django docs:
https://docs.djangoproject.com/en/dev/topics/python3/#str-and-unicode-methods

Both the master branch and Django 1.7 branch introduced a South
migration for offers. It's been addressed by dropping the one introduced
on the Django 1.7 branch, and re-creating it.

The native migrations have been completely recreated.

That puts it in line with Oscar's naming conventions.

New style migrations created with the helper script. Now doesn't detect
any more changes after this set has been applied.

I don't know how I missed them. I think I must've made a mistake while
heavily rebasing this branch; it's the second time I'm surprised to not
find certain changes I'm confident I did.

That way, the app names can be localised, which e.g. makes the Django
admin interface nicer.

This is necessary, as Django 1.7 enforces that a model can only be
registered once. Previously, declaring a model a second time would lead
to the second declaration being silently ignored.

The changes have been automated by this gist:
https://gist.github.com/maikhoepfel/05e047e0205f576da1a6

This change might need to be re-applied if more migrations get added
before this PR is merged into master.

More changes need to be done regarding migrations; this commit just
moves them out of the way so that Django doesn't pick them up.

Also register the signal receivers in the ready() method for 1.7+

In Django >= 1.7 this will be done via the AppConfig

It just duplicates ProductRecord.score, makes ``oscar_calculate_scores``
slow and generally serves no useful purpose.

Also included docs for the previous changse to
``oscar_calculate_scores``.

The Django ORM is perfectly capable. F() expressions FTW!

Unfortunately, this exposed a bug in the raw SQL, affecting both SQLite
and PostgreSQL. I'm somewhat confident that previously, only num_purchases
was divided by the total weight.

Will write docs later so I can link to this commit.

Issue #1033 is related.

The old behaviour was to issue a get_or_create call, and then increase
a counter field and save the new instance. That will have caused 2 (or
even 3 on older Django versions) queries. The new behaviour now is to
use update() and only issue a create if no instances were affected.

Fixes #806

We now have a proper search app for searching.  We don't need the simple
search within the catalogue app anymore.

This should always be used instead of Django's silent version.

This reverts fa1f8403 which moved them from models.py to __init__.py.
As reported by @mvantellingen, importing receivers from __init__.py
breaks the way models are normally overridden as it causes the core
models.py to get imported before the custom one.

We need to move back to the old system and will need to advise that the
debug toolbar needs to be set-up explicitly to avoid circular import
issues with models.

Fixes #1159
Original issue #1125

This is to avoid circular import issues as most receivers.py modules
also import models.  It's not entirely clear what circumstances are
required to get the circular import - it seems to be when using
django-debug-toolbar>=1.0, which changes the way the URLs are
monkey-patched.

This changes adopts the recommended practice for importing signal
receivers:

- https://groups.google.com/forum/#!msg/django-developers/PReHoxwwG_c/M-asj72ks7YJ
- http://stackoverflow.com/a/14192257/25517

Fixes #1125 (I think)

Use double quotes(") instead of grave accents (`) to avoid DatabaseError while running 'python manage.py oscar_calculate_scores'

As discovered in #1003, some fields of ModelForms were not translated.
The issue is that we've used ugettext instead of ugettext_lazy. The
former will be translated whenever model definitions are loaded, whereas
the latter will translate at the last possible moment. Only then do we
know of the appropriate language to use. Hence, we must use
ugettext_lazy for all model defintions.

Using example classes from http://docs.python.org/2/library/csv.html#examples

Fixes #390

Was breaking on Sqlite3.  It's a bit basic at the moment but work ok for
sites with small catalogue sizes.

The dates should be picked up correctly by Excel now.

The initial one is for the releases/0.1 branch - any others are to
handle changes in the 0.2 branch.

Now they are always available within the oscar app.

- Also refactored the calculate scores management command