Re: i18n docs
Hello, On IRC, Bas Peschier pointed out that the current docs follow the "definitions" of i18n and l10n. In fact, the code (in particular the settings) uses the "gettext" definitions while the docs use the more general "Wikipedia" definition, and confusion ensues. For consistency, I think the docs should reflect the assumptions of the code. So I'm proposing the following clarification: > Definitions > === > > Different people give different meanings to the words "internationalization" > and > "localization". > > Django follows the definitions from the `GNU gettext documentation`_: > > * Internationalization means supporting multiple languages; > * Localization means supporting multiple input and output formats. > > In short, internationalization is about text, localization is about data. > > The `Wikipedia article`_ and the `W3C Web Internationalization FAQ`_ have a > different approach: > > * Internationalization means preparing the software for localization; > * Localization means writing the translations and local data. > > From this point of view, internationalization is for developers, localization > is for translators. > > Although the latter definition is more common and possibly more correct, > Django > sticks with the former. Developers being the primary audience, a thematic > approach makes more sense. It's more consistent with the implementation too. > > .. _W3C Web Internationalization FAQ: > http://www.w3.org/International/questions/qa-i18n > .. _GNU gettext documentation: > http://www.gnu.org/software/gettext/manual/gettext.html#Concepts > .. _Wikipedia article: > http://en.wikipedia.org/wiki/Internationalization_and_localization Does this make sense? -- Aymeric Augustin. On 22 oct. 2011, at 00:10, Aymeric Augustin wrote: > Hello, > > Maybe it's just me, but I find the i18n docs quite confusing, and I often > struggle to locate the information I need: > https://docs.djangoproject.com/en/1.3/topics/i18n/ > > For instance, I don't understand why: > - the index page immediately dives into gettext technicalities; > - /topics/i18n/localization/ describes how to write .po files and how to use > the localization features of Django (USE_L10N), two seemingly unrelated > topics; > - implementation details of i18n are split between /howto/i18n/ and > /topics/i18n/deployment/. > > In the context of my timezone support branch, I'd like to clarify all this. > > I regard internationalization as the combination of three things: > 1 - USE_I18N = translation, per language > => translating text in code and templates -- USE_I18N is an > unfortunate choice for the translation setting, but that's history) > 2 - USE_L10N = localization, per country > => formatting dates, times, numbers -- possibly currencies and > units in the future > 3 - USE_TZ = time zone, per region > => converting datetimes > > I think there should be an index page and one page for each of these three > topics. > > What do you think? Have I missed something? > > Thanks, > > -- > Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: i18n docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Aymeric, On 10/22/2011 05:02 AM, Aymeric Augustin wrote: > On IRC, Bas Peschier pointed out that the current docs follow the > "definitions" of i18n and l10n. > > In fact, the code (in particular the settings) uses the "gettext" > definitions while the docs use the more general "Wikipedia" > definition, and confusion ensues. > > For consistency, I think the docs should reflect the assumptions of > the code. So I'm proposing the following clarification: > >> Definitions === >> >> Different people give different meanings to the words >> "internationalization" and "localization". >> >> Django follows the definitions from the `GNU gettext >> documentation`_: >> >> * Internationalization means supporting multiple languages; * >> Localization means supporting multiple input and output formats. >> >> In short, internationalization is about text, localization is about >> data. >> >> The `Wikipedia article`_ and the `W3C Web Internationalization >> FAQ`_ have a different approach: >> >> * Internationalization means preparing the software for >> localization; * Localization means writing the translations and >> local data. >> >> From this point of view, internationalization is for developers, >> localization is for translators. >> >> Although the latter definition is more common and possibly more >> correct, Django sticks with the former. Developers being the >> primary audience, a thematic approach makes more sense. It's more >> consistent with the implementation too. >> >> .. _W3C Web Internationalization FAQ: >> http://www.w3.org/International/questions/qa-i18n .. _GNU gettext >> documentation: >> http://www.gnu.org/software/gettext/manual/gettext.html#Concepts .. >> _Wikipedia article: >> http://en.wikipedia.org/wiki/Internationalization_and_localization > > Does this make sense? I'm an expert in neither internationalization nor localization, but I do think that our code (in particular the highly user-visible bits like settings) should use the same definitions as our docs, otherwise we're just asking for confusion. And it's a lot easier to change the docs than to make backwards-incompatible code changes. So unless there is a really compelling reason to use the Wikipedia/W3C definitions, I agree with your proposed change. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6i5rMACgkQ8W4rlRKtE2eMlACfQryWkcDVkM2dVi4aYML9fnOr +NQAoIlH4rME4kYgw6S+/rCLsxfrxXsz =8BtB -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: i18n docs
On 22 oct. 2011, at 17:52, Carl Meyer wrote: > I'm an expert in neither internationalization nor localization, but I do > think that our code (in particular the highly user-visible bits like > settings) should use the same definitions as our docs, otherwise we're > just asking for confusion. And it's a lot easier to change the docs than > to make backwards-incompatible code changes. So unless there is a really > compelling reason to use the Wikipedia/W3C definitions, I agree with > your proposed change. In fact, neither of my two emails was accurate :( I had misread the GNU gettext docs: they agree that internationalization = the developer's job and localization = the translator's job. This is absolutely counter-intuitive for someone like me who discovered Django's USE_I18N and USE_L10N first. I've attempted to sidestep the issue in our docs by: - calling USE_I18N-related stuff "translation" and USE_L10N-related "formatting", - avoiding the words "internationalization" and "localization" as much as possible, - warning that the names of the settings are historical. In the process, I've proof-read all the i18n docs, edited them lightly, and removed some duplication (especially with the i18n howto). Given that I've moved files and chunks of text around, the result was hardly possible to review, so I committed it at r17026, after checking that I didn't lose any text. Further improvements are certainly possible, feedback welcome. Thanks, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: The state of per-site/per-view middleware caching in Django
On Oct 21, 9:17 pm, Jim Dalton wrote:
> On Oct 21, 2011, at 8:04 AM, Kääriäinen Anssi wrote:
>
> > I do not know nearly enough about caching to participate fully in this
> > discussion. But it strikes me that the attempt to have CSRF protected
> > anonymous page cached is not that smart. If you have an anonymous
> > submittable form, why bother with CSRF protection? I mean, what is it
> > protecting against? Making complex arrangements in the caching layer for
> > this use case seems like wasted effort. Or am I missing something obvious?
>
> First issue is that CSRF can matter for anonymous users. From
> herehttp://www.squarefree.com/securitytips/web-developers.html#CSRF:
>
> Attacks can also be based on the victim's IP address rather than cookies:
>
> • Post an anonymous comment that is shown as coming from the victim's
> IP address.
> ...
> • Perform a distributed password-guessing attack without a botnet.
> (This assumes they have a way to tell whether the login succeeded, perhaps by
> submitting a second form that isn't protected against CSRF.)
>
> So two very common uses cases for anonymous forms are log in forms and
> anonymous comment forms, both of which are potentially vulnerable. I guess I
> feel like it's quite common to have forms on a page these days even for
> anonymous users.
>
> Second is -- and I don't know about this -- but I don't know how well CSRF
> handles authentication conditionally. Like if I have a page and let's say
> that page has forms in it for logged in users but nothing for anonymous user,
> can I conditionally exempt the formless page from CSRF? I have no idea, but
> buy default I presume it's on and I presume the cache is varying on it.
>
> So, yes, you could probably optimize a lot of this to sort of skip around the
> CSRF issue and it's not a deal breaker. But my main argument has been the
> ubiquity of CSRF + user authentication in Django projects to me means a
> solution to both of these is a requirement for page caching to become easy
> and applicable in most scenarios.
I can see how the above mentioned cases are useful, and as you say,
they probably are common in real world usage.
I took a different approach to phased template rendering in [https://
github.com/akaariai/django/tree/rewritable_content]. I hope it will
give some insight into solving the rewriting of already rendered
content containing csrf_token.
The idea is that template.render(context) returns a subclass of
SafeUnicode instead of just SafeUnicode. The subclass knows the
positions of rewritable parts of the content (csrf token values, for
example), and also how to rewrite those parts of the content. So, from
a template {% csrf_token %} you could get something like this back:
>>> rendered = tmpl.render(Context({'csrf_token': 'CSRF_TOKEN_VALUE'}))
>>> str(rendered)
# (pseudoish...)
>>> rendered.rewritable_parts
{'csrf_token': [(27, 42)]} # a dictionary of rewritable name -> list
of str positions where that block exists.
>>> rendered.rewrite({'csrf_token': 'NEW_VALUE'})
There are some tests in the github branch. Those tests are the best
documentation currently available.
Rewritable rendered templates should be usable in automatic handling
of csrf_token when solving the caching problem. If you do no caching,
the user will get a normal response. If you do caching, then you will
need a hook to do the response.rewrite for the csrf_token in cache
fetching. This has been discussed already, and seems to be solvable.
The actual rewrite of the content would be easy, it is just
response.rewrite({'csrf_token': 'new_csrf_token_value'}). This way it
could be possible to cache pages containing csrf_token transparently
to the user.
The github branch also implements {% rewritable some_name %} {%
endrewritable %} tag, but as is it is not very usable. For example,
rewriting the login/logout part of the page would be much easier using
a real two-phase rendering implementation. The already mentioned
Jannis Leidel's django-phased seems to fit this task much better than
my hack.
As far as I can tell there isn't any large performance hit (actually,
using djangobench, I could not measure any difference). This might be
just a failure on my part, as that result is a bit surprising.
The biggest problem with the approach is that the csrf_token tag must
be rendered as part of nodelist. If it isn't the tracking of
start_pos,end_pos of the rewritable content will get out of sync. This
alone might be a show-stopper. I would not be surprised if there are
other non-solvable problems with the approach. All I know is that it
seems to work with include and block tags in simple templates.
The current implementation is just a quick hack. As said above, it is
possible, if not likely, that this approach is a dead-end.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegr
Django Docs for Forms - Alternative Pattern from Advanced Django Forms Usage talk?
heya,
*Disclaimer: This is about the the Django Docs, and a possible suggestion
for it - apologies if this isn't the correct group (but I didn't think it
quite fell into django-users).
*
The official Django Docs for forms offers up the following pattern for Form
view code:
def contact(request):
> if request.method == 'POST': # If the form has been submitted...
> form = ContactForm(request.POST) # A form bound to the POST data
> if form.is_valid(): # All validation rules pass
> # Process the data in form.cleaned_data
> # ...
> return HttpResponseRedirect('/thanks/') # Redirect after POST
> else:
> form = ContactForm() # An unbound form
> return render_to_response('contact.html', {
> 'form': form,
> })
https://docs.djangoproject.com/en/dev/topics/forms/
I was just viewing a talk by pydanny and Miguel Araujo at DjangoCon US 2011
on "Advanced Django Form Usage", and they offered up what they seem to feel
was a better pattern for form viewcode:
def some_view(request, template_name="someapp/someform.html")
> form = MyForm(request.POST or None)
> if form.is_valid():
> do_x()
> return redirect('Home')
> return render(request, template_name {'form': form}).
http://speakerdeck.com/u/pydanny/p/advanced-django-forms-usage (Slide 13)
Now, apart from being shorter, I don't think I know enough about Django or
forms to know which one is actually "better" overall. However, what's the
community's consensus on this?
If it is better, is there any scope for having it in the official Django
docs? Or even adding it as an alternative approach, and discussing the
pros/cons?
Cheers,
Victor
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/elI_Os49thcJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django Docs for Forms - Alternative Pattern from Advanced Django Forms Usage talk?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Victor,
On 10/22/2011 06:57 PM, Victor Hooi wrote:
> /Disclaimer: This is about the the Django Docs, and a possible
> suggestion for it - apologies if this isn't the correct group (but I
> didn't think it quite fell into django-users).
No worries, you've got the right list. Developing the Django docs is
part of developing Django, and this list is about developing Django.
> The official Django Docs for forms offers up the following pattern for
> Form view code:
>
> def contact(request):
> if request.method == 'POST': # If the form has been submitted...
> form = ContactForm(request.POST) # A form bound to the POST data
> if form.is_valid(): # All validation rules pass
> # Process the data in form.cleaned_data
> # ...
> return HttpResponseRedirect('/thanks/') # Redirect after
> POST
> else:
> form = ContactForm() # An unbound form
> return render_to_response('contact.html', {
> 'form': form,
> })
>
>
> https://docs.djangoproject.com/en/dev/topics/forms/
>
> I was just viewing a talk by pydanny and Miguel Araujo at DjangoCon US
> 2011 on "Advanced Django Form Usage", and they offered up what they seem
> to feel was a better pattern for form viewcode:
>
> def some_view(request, template_name="someapp/someform.html")
> form = MyForm(request.POST or None)
> if form.is_valid():
> do_x()
> return redirect('Home')
> return render(request, template_name {'form': form}).
>
>
> http://speakerdeck.com/u/pydanny/p/advanced-django-forms-usage (Slide 13)
>
> Now, apart from being shorter, I don't think I know enough about Django
> or forms to know which one is actually "better" overall. However, what's
> the community's consensus on this?
I think this might have been mentioned in an audience question at that
talk: the shorter code does have an edge-case problem. It is possible
for request.method to be "POST" and for request.POST to be empty.
(Browsers generally won't do that, they'll submit empty strings; but
forms are useful for validating data from other sources as well, such as
API clients). For some (less common) forms, this could even be a valid
form submission (if no fields are required). In the other cases, it
should really return a bound, not-valid form, with one or more "This
field is required" validation errors. With the shorter code, it will
instead return the unbound form again.
This problem can be fixed by changing the form instantiation to:
form = MyForm(request.POST if request.method == "POST" else None)
At this point, though, I'm no longer convinced that it's much simpler or
more readable.
The other advantage of the longer version is that if you need to add
request.FILES handling to the form, for instance, it's clearer and
simpler how to do that.
> If it is better, is there any scope for having it in the official Django
> docs? Or even adding it as an alternative approach, and discussing the
> pros/cons?
I think the issues with the short version are subtle and advanced enough
that they'd be a serious distraction at that point in the docs, and the
gain just isn't worth the need to introduce that discussion. The
currently-documented version is good enough (TM), and it's more explicit
about what's going on.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6jgIIACgkQ8W4rlRKtE2dIzACgt4lh06OKTeCyb1cGPnKKYq8h
twUAoM21MaExW6uLk/DxgUzaKcbwEQFb
=EWnD
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
