Localisation

Translations for the texts in the interface are provided in a set of files in the locale catalogue in the LANG_oahpa catalogue, where LANG should be replaced with your language's ISO code (note that the sme Oahpa does not follow standard and is located in the folder univ_oahpa): 

ped/LANG_oahpa/locale/fi/LC_MESSAGES/django.po
ped/LANG_oahpa/locale/sme/LC_MESSAGES/django.po
ped/LANG_oahpa/locale/no/LC_MESSAGES/django.po
ped/LANG_oahpa/locale/en/LC_MESSAGES/django.po

The English file is needed for the names and strings that contain Unicode. The English texts in the html-pages in LANG_oahpa/LANG_drill/templates should be ascii.

Whenever the texts in the page are updated, the translations need to be checked and updated as well. 

cd ped/oahpa
python manage.py makemessages -a
svn ci -m "new generated files" locale/fi/LC_MESSAGES/django.po
   ... etc. for the other files.

If the Oahpa installation uses virtualenv you might need to specify that makemessages ignore virtualenv directories, otherwise many more strings will be included than need to be. ex: python manage.py makemessages -a --ignore=env/*

(Note: For this to work, your manage.py and your django installation must be tune with each other. See the django documentation.)

After that, work on the respective django.po files, and check them in again. Search for word "#fuzzy" from django.po. It means that the English content has changed and the system tries to guess the correct translation. Check the translation and remove all the lines that contain "#fuzzy", otherwise the translation does not work.

After fixing the files update the official directory and compile the messages. 

cd ped/oahpa/
svn up
python manage.py compilemessages --ignore=env/*

If you are not allowed to compile the messages (the machine requires sudo rights), remove the  *.mo files: 

rm -f locale/*/LC_MESSAGES/django.mo

Thereafter, repeate the compile message.

After the messages have been compiled, restart the server (exchange univ_oahpa with smaoahpa, kom_oahpa, etc): 

sudo service univ_oahpa restart

This is an alias, to be written anywhere, for the command sudo /home/univ_oahpa/univ_oahpa/run_fastcgi.sh, and correspondingly for smaoahpa, etc. Note that server maintenance and restart is documented in the document httpdserver.jspwiki

New localisations

Django has two locations for localisations, one is the "global" level, which contains translation strings for the Django administrative interface, and a local project level, the management of which is described above. Django does not allow creation of new localisations if the global level does not contain a directory containing translation strings. To save time, the global level does not need to contain translation strings for, for example, Northern Sámi, because end users will never see the internal global strings.

Creating a new localisation

Locate the site-packages directory for the version of python in use. The easiest way to locate them is from the oahpa project directory by using the Python command-line interpreter. 

	./manage.py shell
	>>> import django
	>>> django
	<module 'django' from '/usr/lib/python2.6/site-packages/django/__init__.pyc'>

In the directory that is returned, navigate to the locale directory 

    cd /usr/lib/python2.6/site-packages/django/conf/locale/

Then copy one of the existing folders to a new folder with the language code for the localisation. 

	cp -R nn sma

settings.py

The project's settings.py file must be modified to include the localisation language, so that administrative commands will work. 

	LANGUAGES = (
		('sma', 'South Sami'),
		('no', 'Norwegian'),
		('sv', 'Swedish'),
		('en', 'English'),
	)

After completing these steps, it will be possible to work with and see local project-level localisation strings in the application.

Official documentation

Django localisation documentation