Howdy folks --
I've had a chance to review the i18n branch, and here are my thoughts:
1. Awesome. Seriously, this rocks; all of my criticisms to follow
are trivial next to how cool this is.
2. Once this hits the trunk we'll need documentation about any
backwards incompatibilities this introduces and what the upgrade path
looks like (in the style of the docs on the
BackwardsIncompatibleChanges page). The translation document is great
3. I don't like that the translation context can be specified in the
GET string (i.e. http://www.example.com/?django_language=en). I hate
exposing the framework in that way; URLs should reveal anything about
the underlying architecture (leaky abstractions and all that). It's
certainly a convenient way to set the language from a link or
whatever, but I'd rather that be relegated to a simple view (which
sets the language and then redirect back to the previous page) then
have it be an aspect of the middleware as it is now. Similarly,
exposing LANGUAGES in DjangoContext seems like overkill; a template
tag seems like the best idea::
{% load i18n %}
{% get_available_langauges as languages %}
{% for langauge in languages %}
...
{% endfor %}
4. I don't like that you have to explicitly provide the verbose_name
for fields if you want the field names translated; we specifically
removed verbose_name as a required attribute because it was a PITA,
so if there's a way around doing::
name = meta.CharField(_('Name'))
that would be awesome. I understand that the _ is needed to mark the
string as translatable, but perhaps there's a way in the script that
gathers strings to do that automatically?
5. Similarly, I don't like the changes to the template code.
Basically, I don't want to have to explain i18n to template authors
(they shouldn't have to know anything about it) and explaining why
someone needs to do::
<title>{{ _('Title') }}</title>
instead of just::
<title>Title</title>
And *I* barely understand what::
<p>{% i18n ngettext('There is %(count)d file', 'There are %
(count)d files', files|count) %}</p>
is doing, and "leaking" %-style string formatting into the template
code seems ugly. Specifically, I'd like the template language to be
as losely coupled to Python as possible; I'd like implementations of
the template language on other platforms to be possible.
We've deliberately kept the template language as simple as possible,
and I feel like this damages it. I'm not sure how to get around it
(again, I understand how you've got to mark the template files for
string collection), but off the top of my head I'd like to see
something like::
<title>{% translate "Title" %}</title>
<p>{% translate %}Hello, {{ name }}, welcome to {{ site }}!{%
endtranslate %}</p>
<p>{% translate %}There are {{ count }} {% pluralize count
"file" "files" %}{% endtranslate %}</p>
In this sketch, {% translate %} as a non-block tag (when it has
arguments) replaces {{ _('title') }}; as a block tag (when it's got
no arguments) it replaces {% i18n _(...) %}, and {% pluralize %}
within a translate block replaces {% i18n ngettext %}.
Thoughts?
Once again, hugo, I can't thank you enough for your hard work.
Watching my admin change languages was so cool I could barely keep
from dancing :)
Jacob
