I haven't had a chance to explore the i18n branch yet, but I plan to spend some quality time with it tonight. Preliminary thoughts, based on the current discussion, are below --
On 11/2/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > 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). Agreed. Looks like Hugo has solved this one with a view. > 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 %} Agreed here, as well. And I'd stress that {% load i18n %} should be necessary, so as not to clutter up the default tags for people who don't need it. Modularity and all that. > <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. Agreed WHOLEHEARTEDLY! We've avoided Python syntax in template tags thus far, and this proposal goes completely against that. I must say I like Ian's proposal that the template_loader could load a different template based on language. That would avoid this whole problem, and it'd allow for more language-specific flexibility -- e.g. displaying different background colors or images, including different JavaScript modules, etc., for different languages. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
