USE_I18N vs. USE_L10N
Lucy Brennan
and localization, e.g. as defined on http://en.wikipedia.org/wiki/Internationalization_and_localization.
Internationalization is somewhat like building/designing a piece of
software for being used with different locales. And localization is
then making some localized version withing the boundaries set by the ,
e.g. making all the translated versions and date formatting for
Germany.
According to those definitions, I think it makes sense to "turn off
i18n and l10n". But what does it mean to turn of one and not the
other?
They only make sense in relation to each other, and turning one of
without turning the other off, does not make sense to me.
I don't think it is obvious what they do?
Lucy
Shawn Milochik
If you look up those terms in the Django docs instead of Wikipedia I think that will erase your confusion.
Lucy Brennan
get your response to my email. I only saw your answer because I went
to the online archive.
Here is a follow up for the googlers.
I have read the Django documentation, e.g.: https://docs.djangoproject.com/en/dev/topics/i18n/,
which in my opinion says just about the same as Wikipedia, regarding
the meaning of those two words.
The Internationalization article (https://docs.djangoproject.com/en/
dev/topics/i18n/internationalization/), explains about
internationalization in Django, but does not explain what it means to
disable/enable it. I guess that disabling internationalization means
disabling translation.
The Localization article (https://docs.djangoproject.com/en/dev/topics/
i18n/internationalization/), explains about Localization in Django,
and mentions in short about the USE_L10N parameter. Apparently it
decides if localized formatting of e.g. dates should be used.
For both the USE_L10N and USE_I18N their effect is not obvious from
their naming. I suggest, that the description of these parameters in
https://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs are
made more precise.
From what I understand, they should have had names like
USE_TRANSLATION and USE_LOCALIZED_FORMATTING.
Lucy
Andre Terra
For both the USE_L10N and USE_I18N their effect is not obvious from
their naming. I suggest, that the description of these parameters in
https://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs are
made more precise.
From what I understand, they should have had names like
USE_TRANSLATION and USE_LOCALIZED_FORMATTING.
+1 on that. Actually, I'd +over 9000 if I had the power.
Cheers,
AT
Tom Evans
I strongly disagree, i18n and l10n have explicit and well known
technical meanings, dating from the late 80s. It is right and proper
to use those names in django, as they are used in every other project
under the sun.
Cheers
Tom
kenneth gonsalves
> I strongly disagree, i18n and l10n have explicit and well known
> technical meanings, dating from the late 80s. It is right and proper
> to use those names in django, as they are used in every other project
> under the sun.
+1
Lachlan Musicman
And mine makes it +2
--
The butter lamb, also known as a buttered lamb, is a traditional
butter sculpture accompanying the Easter meal for many Slovenian and
Polish Catholics. Butter is shaped into a lamb either by hand or in a
lamb-shaped mould. Frequently the eyes are represented by peppercorns
and a white banner with a red cross on a toothpick is placed on its
back. (via http://bestofwikipedia.tumblr.com/ )
Benedict Verheyen
> On Wed, Jul 27, 2011 at 16:53, kenneth gonsalves <law...@thenilgiris.com> wrote:
>> On Tue, 2011-07-26 at 15:09 +0100, Tom Evans wrote:
>>> I strongly disagree, i18n and l10n have explicit and well known
>>> technical meanings, dating from the late 80s. It is right and proper
>>> to use those names in django, as they are used in every other project
>>> under the sun.
>>
>> +1
>
> And mine makes it +2
>
>
>
Just to add my 2 euro cents, I think both opinions have merit to some point but in the
end, it's better to leave the technical terms as it forces the programmer to search
more info on these topics to know what they mean.
For a person with no experience with translations or internationalization, the terms
don't mean a thing and aren't clear at all.
A more technical person will however immediately recognize these names and know what
they mean and how they work.
However, you can argue that a programmer needs to check the background info on
translation/internationalization before using it (which they should).
If they do, they'll know the terms i18n and l10n, and that's the whole point.
Cheers,
Benedict
Lucy Brennan
USE_I18N: translation
USE_L10N: localized formatting
Right?
Masklinn
Lucy Brennan
So there seems to be two pairs of definitions for I18N / L10N:
a) I18N / L10N ~ (building software so ready to be locale-language-customized / making a specific localized version )
b) I18N / L10N ~ (translation/localized formatting)
When reading Wikipedia (http://en.wikipedia.org/wiki/Internationalization_and_localization). I understand the option a), and I don't think they mention that the terms can have different meanings. When reading Django's article https://docs.djangoproject.com/en/dev/topics/i18n/, I get exactly the same understanding.
People in this thread talk about meaning b) as if it is a long established meaning and common knowledge. So I guess it is. But I did not find anything describing this meaning when I was trying to figure out what USE_L10N and USE_I18N meant.
So if you are so certain that I18N / L10N are common knowledge for translation/localized formatting, I suggest that you add that knowledge to the abovementioned Wikipedia article and Django documentation article.
Furthermore, the https://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#use-i18n, should not just say that it will "turn off the internationalization machinery", since that is not helpful unless "internationalization machinery" is defined. And come on, why not just add that this is translation.
Lucy
kenneth gonsalves
wrong
Mike Dewhirst
Russell Keith-Magee
Ok - seriously, Kenneth - if you're not going to take the time to
provide a full answer (with sentences, capitalization and all the
trimmings), please refrain from answering at all. A single word
response doesn't contribute anything to the discussion, and just makes
the whole community seem rude.
Lucy: Although there are a lot of people that use L10N and I18N
interchangeably, they are very distinct terms; any source you find
that uses them interchangeably is categorically wrong. However, the
two are very closely related, because localization usually happens in
the presence of internationalization, and vice versa -- hence the
common confusion. Although they share a Wikipedia page, if you read
the rest of the page, you'll see they make a distinction between a
localized system and an internationalized system.
To a first approximation, your translation vs formatting dissection
reflects Django's usage of the terms. I agree that Django's
documentation doesn't do the best job at pointing out the distinction
between the two (either in general, or in Django's interpretation. It
would certainly be worth opening a ticket to point out this limitation
of the existing docs.
If you feel like contributing, producing a patch to Django's
documentation to clarify the usage of i18n and l10n would be an
excellent way to get involved. It has been my experience that
newcomers often write the best high-level docs, because they're the
people who don't have any preconceived ideas, so they know what isn't
obvious, and what needs to be explained.
To the rest of this thread: I want to head something off at the pass
right now -- consider it a core-team decision that we're not going to
rename these settings. I18n and L10n are well understood terms to
anyone who has been dealing with adapting software to multiple
languages and cultures reasonable descriptions of what Django does
with the USE_I18N and USE_L10N settings, and we're not going to change
the values because someone comes up with a slightly better name. There
needs to be something fundamentally wrong or misleading before we
would even consider changing the name of a setting, and given that
these settings have been in the wild successfully for some time (I
think it's 4 years in the case of USE_I18N) you're not going to find
that here.
Yours,
Russ Magee %-)
kenneth gonsalves
> >> USE_I18N: translation
> >> USE_L10N: localized formatting
> >>
> >> Right?
> >
> > wrong
>
> Ok - seriously, Kenneth - if you're not going to take the time to
> provide a full answer (with sentences, capitalization and all the
> trimmings), please refrain from answering at all. A single word
> response doesn't contribute anything to the discussion, and just makes
> the whole community seem rude.
apologies - my LUG legacy still peeps out occasionally.
Masklinn
That's not what the Django documentation says, at least in my reading of it.
Masklinn
> Lucy: Although there are a lot of people that use L10N and I18N
> interchangeably, they are very distinct terms; any source you find
> that uses them interchangeably is categorically wrong. However, the
> two are very closely related, because localization usually happens in
> the presence of internationalization, and vice versa -- hence the
> common confusion. Although they share a Wikipedia page, if you read
> the rest of the page, you'll see they make a distinction between a
> localized system and an internationalized system.
I18N are, she was asking what USE_I18N and USE_l10N do. In Django.
> To the rest of this thread: I want to head something off at the pass
> right now -- consider it a core-team decision that we're not going to
> rename these settings. I18n and L10n are well understood terms to
> anyone who has been dealing with adapting software to multiple
> languages and cultures reasonable descriptions of what Django does
> with the USE_I18N and USE_L10N settings, and we're not going to change
> the values because someone comes up with a slightly better name. There
> needs to be something fundamentally wrong or misleading before we
> would even consider changing the name of a setting, and given that
> these settings have been in the wild successfully for some time (I
> think it's 4 years in the case of USE_I18N) you're not going to find
> that here.
I think the issue with USE_I18N is not so much that it's been kept, but
that it was not expanded to cover USE_L10N's scope as well, with the
ability to enable or disable each subsection of the domain
(translations and localisation of value formats) added on top of that.
I would have made more sense, to me, if USE_I18N enabled *all* of the
relevant l10n, m17n and i18n machinery and if new processes in this
field were added to the flag's purview as they were introduced, bringing
a django project with USE_I18N enabled ever closer to full "effective"
internationalization.
kenneth gonsalves
> > wrong
> That's not what the Django documentation says, at least in my reading
> of it.
i18n - preparing an app to be customised in *any* locale
l10n - actually customising it for a *particular locale
One can do i18n *without* doing *any* translation. i18n - marking
strings for translation, l10n - translating the marked strings.
Russell Keith-Magee
If you think things could work better -- we accept patches :-)
However, before you embark on a massive rewrite of Django's i18n and
l10n systems, keep in mind that there are entirely valid historical
reasons why the settings act the way they do -- mostly to do with
maintaining backwards compatibility and retaining the ability to opt
into potentially expensive (and confusing) options. Any proposal to
change Django in a way that loses either of those properties won't be
looked upon favorably.
In particular, if you think the capabilities of USE_L10N could be
subsumed by an expanded interpretation of USE_I18N, I think you need
to take a much closer look at Django's source code, and the mailing
list discussions that led to the introduction of the USE_L10N setting.
Yours,
Russ Magee %-)
Mike Dewhirst
I've been reading it since this thread began because I want to
understand it. I'm finding it quite hard going but I think I'm getting
somewhere. Here are the bookmarks I have on the topic so far ...
https://docs.djangoproject.com/en/dev/topics/i18n/ -
Internationalization and localization
https://docs.djangoproject.com/en/dev/topics/i18n/internationalization/
- Internationalization
https://docs.djangoproject.com/en/dev/topics/i18n/localization/ -
Localization
https://docs.djangoproject.com/en/dev/topics/i18n/deployment/ -
Deployment of translations
https://docs.djangoproject.com/en/dev/howto/i18n/ - Using
internationalization in your own projects
... and maybe when I've got it working I'll do an noob's overview.
hth
Mike
kenneth gonsalves
> https://docs.djangoproject.com/en/dev/topics/i18n/internationalization/
> - Internationalization
>
> https://docs.djangoproject.com/en/dev/topics/i18n/localization/ -
> Localization
>
> https://docs.djangoproject.com/en/dev/topics/i18n/deployment/ -
> Deployment of translations
>
> https://docs.djangoproject.com/en/dev/howto/i18n/ - Using
> internationalization in your own projects
>
> ... and maybe when I've got it working I'll do an noob's overview.
remember that all these were one page originally (and perhaps easier to
understand.
Lucy Brennan
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???
So since I could not figure that out, I started looking for explanations. And somewhere I found, that the settings meant respectively: translation and localized formatting. And that is why I sent this post on quite a detour. Sorry about that.
Do you people realize that if a newbie reads a) Wikipedia on I/L b) Django on I/L, c) this thread. They will still not understand what those two settings do!
@ Russell: I would not hesitate to help writing the documentation. But I simply don't know what those settings do. So I can't write it. (tragicomic smiley)
Lucy
Mike Dewhirst
> 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.
If there is someone with experience in this area who can comment on this
or correct it please?
Thanks
Mike
>
> So since I could not figure that out, I started looking for
> explanations. And somewhere I found, that the settings meant
> respectively: translation and localized formatting. And that is why I
> sent this post on quite a detour. Sorry about that.
>
> Do you people realize that if a newbie reads a) Wikipedia on I/L b)
> Django on I/L, c) this thread. They will still not understand what
> those two settings do!
>
> @ Russell: I would not hesitate to help writing the documentation. But
> I simply don't know what those settings do. So I can't write it.
> (tragicomic smiley)
>
> Lucy
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/d9ShQzQ7tnsJ.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
Russell Keith-Magee
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 %-)
Mike Dewhirst
Thank you for the clarification. Just a couple of questions below ...
On 1/08/2011 11:09pm, Russell Keith-Magee wrote:
> 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.
I can see those in django.conf.global_settings
> If USE_L10N is enabled, the formats.py file
> corresponding to the currently enabled language will be used to
> determine date/number formats.
settings.LANGUAGE_CODE determines the "currently enabled language" as
implied by the comment in the django-admin generated settings.py - if it
hasn't been set in some other way as you mention above. But looking
ahead to your next point below, should this one also say ".. and
USE_L18N is enabled .."?
>
> * 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.
Do we need *both* USE_L10N and USE_I18N set true to give effect to
date/number formats in the "currently enabled language"?
It makes sense to me that we do. Although, I want localised formatting
long before I want translations.
Thanks
Mike