Django Internationalization
UDPATE: please check the djangoproject, because the situation is much better now...Today I realized that the django way of internationalization is not as good as I had thought. Here are two areas where it could be improved:
The models
Django has no default way of translating fields in models. This is a known shortcoming and was addressed in many plugins (transdb, transmeta, multilingual, multilingual-model, translate, ...) and in a Google Summer of Code project by Marc Garcia.
As I see it, the translation of any kind of data should not be in a seperate table or in a metaclass. Why? Because translation should not be the way to think in the first place. If you have a piece of information that is not universally understandable (like an photograph), than you can assign a language or culture to that information. If your site should be available in several languages, then there is no good reason why one language should be superior (and allowed in the model), while other languages are inferior (and have to go into a translation table). So there is no translation of a first, superior string but there is a piece of information in different, equally important languages.
So, with regard to this poll, the only good option would be to state "this field is language specific" and django should create a field for every supported language (mainly like multilingual-model).
The admin interface should display these fields and a bonus would be to be able to create a report based on the missing translation fields.
The urls
But there are other fields where internationalization is also important and where I couldn't find any plugins or snippets. It's the url resolution. Your apps should have human-readable urls that don't change over time. Suppose you have this url in your shop: "/smartphone/linux/N900" and suppose that "smartphone" is a category that was not planned when the shop was planned but rather entered in the admin as a (translatable) categorization of a specific phone. Now if you want to make this translatable, you have to create a pattern like
"(?P
but how is that supposed to be distinguished from
"(?P
if these things should also be translatable? So the point is: the regular expressions in the url resolution mechanism are not translatable (if the strings are dynamical db content).
What could be done?
The could be an url manager that can receive signals about a change in the urls patterns. And there should be an attribute (db-field, function, ...) in every model or view which can take translatable fields as parameters and create and update the corresponding urlpatterns.