Hi! >I'm just now see that you posted diffs in ticket #65 and created a >branch.
Yep. I did it a bit differently than in youre patch: I tried to boil it down to the smalles possible patch to have everything that is needed to get i18n started, but not too much. I think it's much better to have smaller, dedicated patches that are easier to understand and to apply. So I only added the request middleware (that is totally optional - you can just set a static translation language code if you don't need multi language support) and the bare minimum to get a _() function (and some helpers) to work with django. The rest of my patch will just be the needed changes to django itself to provide the _() hooks to do the actual translation. I did subclass the GNUTranslations, but actually if you want a db store, it's easy to integrate later on. For now I think staying with gettext and .po/.mo is the way to go - you can easily deliver .mo files with your django app to people that want to use your app, but you can't as easily deliver database content. Oh, and the current selected language is in request.LANGUAGE_CODE, so you can find that. I didn't touch the default encoding as django itself is just running on utf-8 - if that is changed some day to have a configureable default encoding, it will be easy to incorporate that into the i18n stuff. Changing the encoding based on some HTTP headers will produce problems if the chosen encoding is less than utf-8 - you can't allways transform stuff the right way. It's better to stick to utf-8 anyway. A list of available translations is more a developer choice than a django choice: even if django delivers a butt-load of languages, this doesn't say that the programmer wants all them selectable: for example if the applications themselves only have fewer languages as translations. But it would be easy to write a template tag that produces a select-tag for all installed languages in the base locale path of django. But that's stuff that shouldn't go into the first i18n patch for django, that's better left for additional patches - keep the i18n patch as small as possible. i18n is complicated enough by itself ;-) But all that doesn't say that there shouldn't be any patches later on that make the i18n stuff friendlier or better or easier - my patch just is there to make i18n _possible_ :-) bye, hugo
