On 23/09/2011 1:45am, nadae ivar wrote:
i check it but not undestand
It takes a bit of study and much concentration. I tried it understand it
myself recently and posed some questions here and got some very good
answers and had my understandings corrected at the time. I still haven't
implemented Internationalization but wrote myself an overview (below) so
I would remember it. It is unfinished and has not been proof-read by an
expert. So if you use it I would appreciated your feedback and any
corrections you feel ought to be made. Here goes ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
Howto - internationalization in your own projects
Objective:
Deploy a Django driven website (consisting of multiple Django apps)
across as many regions as possible but in only a couple of languages.
Overview:
Your Django website consists of server-side software, a database of
information used in your site plus (probably) client-side javascript
software.
To satisfy the "as many regions" part of the objective, you hardly need
to do anything. Django comes with those regional number and date-format
batteries included. Just switch it on with settings.USE_L10N = True.
This is called "localization" - which is part of internationalization
and which also needs to be switched on with USE_I18N = True.
If that is all you do, people in far off lands speaking different
languages and recognising local date and number formats will be more or
less happy. They will be happy about the formats but less happy to see
some screen text in their own language and the rest in your language.
Note - You can restrict the languages from all and sundry to just those
you want with a LANGUAGES setting. See
django.conf.global_settings.LANGUAGES to see the full range. Copy a
LANGUAGES subset into your own settings.py to override this.
The Django team has already translated its own literals into multitudes
of languages. These cover everything Django itself emits which you see.
Similarly, most of the contrib apps also have their literals translated too.
To satisfy the "couple of languages" part of the above objective, you
need to similarly translate any literals in your software into the other
languages you have chosen.
Howto:
1. In settings.py switch on USE_L10N and USE_I18N
Note - USE_L10N == True makes Django use
django.conf.locale.<language>.formats to display numbers, dates and so
on. Otherwise, the formats in django.conf.global_settings are used instead.
But how does Django know which locale's format to use? Answer: The
browser request contains locale settings which are detected by locale
middleware (see below) so that the correct date and number formats are
used. See
https://docs.djangoproject.com/en/dev/topics/i18n/localization/#format-localization
Note - USE_I18N == True is necessary to give effect to USE_L10N. It also
enables all the Django (and contrib app) screen text translations for
all the regions as mentioned in the overview above.
But how does Django know which locale to use? Answer: The browser
request contains a language code from the user's locale. If there is a
translation for that language AND it is enabled (see next point below)
it will be used.
2. In settings.py, optionally restrict the languages to your chosen ones
like this example ...
gettext = lambda s: s # this is a do-nothing workaround against
circular imports
LANGUAGES = (
('fr', gettext('French')),
('en', gettext('English')),
)
3. In settings.py install Django's localization middleware
django.middleware.locale.LocaleMiddleware
Note - In settings.py near the top of the installed middleware the
following sequence should be observed ...
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.middleware.common.CommonMiddleware',
4. Finish your application to the point that screen and print literals
are stable in your own language.
5. For each app used in your site create a "locale" directory with
separate language sub-directories for each of the languages you want to
translate. These sub-directories will contain your translated screen
literals for each app. If your separate apps are intended for release
into the wild it is very important for each to have its own locale
directory for translations.
Note - See the locale language subdirectories in
django.contrib.admin.locale as a guide. If the language you want isn't
there, visit http://www.w3.org/International/articles/language-tags/ and
work out what your language sub-directory name should be.
Note - The "locale" directory doesn't have to be located in each app
directory. It - or they - can be anywhere else provided you nominate the
location in settings.LOCALE_PATHS. If there was a lot of common screen
and print text between the apps you might decide to keep everything
together in a single directory listed in LOCALE_PATHS. You could also
list the unique literals in separate app directories and all the common
literals in a single place. You could also perhaps nominate one app's
locale directory in LOCALE_PATHS as common for all. Translations in
directories listed in LOCALE_PATHS take precedence over those in
app.locale directories with the first translation encountered being the
winner.
6. Create your own translation files for your apps in the languages
specified in settings.LANGUAGES. They belong in
../<wherever>/locale/<language>/LC_MESSAGES/django.po. This is the process:
- mark text to be translated with ugettext
- find the literals with: django-admin.py makemessages
- translate them using a text editor
- compile the translations with: django-admin.py compilemessages
(to be completed)
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
