Hi, I think the i18n branch is ready for merging into trunk. I am using it on two apps (my gallery and my cms project) and it looks quite good to me. I first thought about adding some more translation hooks to the admin before merge, but I think that should wait: rjwittams says his new_admin branch is ready, too, so I thought we'd do it that way:
- merge i18n into trunk - rjwittams merges trunk into his branch - I add translation stuff to his branch - some testing - new_admin goes into trunk There isn't much use in adding translation hooks now to parts of the application that are very likely to be changed in new_admin - that would only add more conflicts on merge. And if we do it the way I listed, rjwittams doesn't need to look for translation hooks in conflicts but can just drop them if in doubt, I will readd them in the next step and send him a patch. The i18n branch currently has translation hooks for validator error messages, for all builtin models and for the current admin templates. What is missing are the whole admin views and dynamic admin templates - but that's something that will most definitely change with new_admin anyway. There are some parts where translations don't apply. These are (from the top of my head): permission names. ----------------- Permission names are currently created in the django-admin.py script and stored in the database. They are created dynamically from the model names, so we can't add static translations. What we could do would be to switch from permission names to permission format strings. A permission would then be "Can add %(plural)s" or "Can delete a %(singular)". These patterns would be static in the current management code and could be marked with gettext_noop and later translated in the admin views. But they would have to be interpolated with the (already translated) model names. Userdefined permissions could be either normal strings (withoug interpolation parts) or patterns just like builtin permissions. But this would be a backward incompatible change (users would have to update their database to the new permission patterns) and it would change admin interface behaviour, so it should go into it's own ticket, maybe solved with new_admin. log lines --------- The admin logs changes to data in a logging table. These entries are generated on the fly and stored in the database. They are not static, but dynamic strings - so we can't provide translations. The same thing as with permission names could apply, though: store string patterns and interpolate later. But this would have to be a bit more complex, as the logline patterns would need access to changed fields' fieldnames and stuff like that, so it would require a bit of datamodel hacking - maybe store the pattern and a pickled dictionary of parameters? Anyway this is beyond the first take at i18n and should go into it's own ticket, maybe solved with new_admin (or solved later on). It's not that bad a problem anyway, as those lines would currently be stored in the language of the changer - and so should be understandable. It only poses a problem where the admin is used by different people with different language settings, as the object history would be a funny mix of languages :-) There are other parts that the i18n branch deliberately doesn't address, like date formats and other l10n stuff. This should really be done in different tickets, maybe even a new branch for the full l10n stuff after i18n and new_admin went into trunk. Another thing that's still open is integration with eggs. Currently i18n relies on translation files stored in the filesystem, so #596 (getting django to run out of an egg) would need to add some support for translation loading from eggs. I tried to limit i18n work to solve the sole problem of "lets get constant strings translated and get a per-request translation selection" part of i18n, to make it easier to understand and merge. There are still things open for implementation outside that narrow goal ;-) Comments? Oh, i18n is current as of [992], there weren't that many conflicts over time, so it should go into trunk quite easily. But due to the big admin-moving patch, I fear it won't go in with simple SVN measures, it's a bit of manual shoving, patching, copying. But if the branch is current to trunk, it should be possible to just manually copy over the changed files (the added files aren't a problem anyway). bye, Georg
