On Mon, Aug 1, 2011 at 9:14 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote: > On 1/08/2011 8:09am, Lucy Brennan wrote: >> >> I read Wikipedia and Django docs. Now, after all this debate, I see that I >> _did_ understand the definitions when I first read it. >> >> Given those definitions however, the meaning of USE_I18N and USE_L10N are >> not obvious. Far, far, far from obvious. There _absolutely_ has to be some >> additional explanation of what those two settings does. How can you even >> think that it is obvious??? > > Can I try and summarise from the perspective of a new user? I want to > include both in my current project so I'm hoping this summary is correct. > Please correct me if I'm wrong ... > > Localisation L10N - if switched on via USE_L10N = True - means try to detect > the user's browser header which reveals the region set in the user's > computer. IF detected AND if there is a > ../site-packages/django/conf/locale/[xx_XX]/formats.py which corresponds > THEN django will magically translate numbers, dates and times accordingly. > > Internationalisation i18n - if switched on via USE_I18N = True - means to > enable translation of string/unicode literals found in the software PROVIDED > the translation mechanism is being used AND translations of the literals > exist. This mechanism involves ugettext.py and use of the language code > deliberately selected by the user from among those on offer which you (the > developer) have made available. The ugettext function goes off and finds the > correct prepared translation file > (../site-packages/django/conf/locale/[xx_XX]/LC_MESSAGES/django.po/.mo) and > uses the literal as an index into that file and returns the translation for > display to the user. That's the django translations. For your own software > translations you have to prepare your own [app].po/.mo file.
Close, but not quite. * USE_I18N turns on the availability of translations at all. If USE_I18N is false, all translation-related activities are no-ops. * Assuming USE_I18N is enabled, the current language can be set using either the browsers language header *or* using a call to a url activating a specific language for a session (django.views.i18n.set_language). Any text marked for translation will use the usual ugettext tools and the .mo data files to determine the translated text. * By default, all numbers and dates are rendered using the global format settings. If USE_L10N is enabled, the formats.py file corresponding to the currently enabled language will be used to determine date/number formats. * If USE_L10N is enabled, but USE_I18N isn't, then the global language code will be used to determine the formats file that is used. * There are a couple of edge cases in form processing around L10N. For reasons of backwards compatibility, localized formatting isn't automatically turned on for the display of form data, so you have to turn on localize=True on every field that you want to display data in a localized format. Yours, Russ Magee %-) -- 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.
