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|httpdserver.html]


!!!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|https://docs.djangoproject.com/en/dev/topics/i18n/localization/]