Notes for the future

[spectras]

Keeping track of ideas for the next evolutions of hvad.
Those evolutions would all require major refactoring of some parts of hvad, so while they are definitely things I will strive for, do not expect any of them soon.

Delayed queryset calls

Right now, all calls to queryset-returning methods are translated and applied onto the queryset immediately. This is detrimental to optimization, as there is no way to get back to those and alter them without taking a deep dive into the ORM's internals.

Especially, the actual application of language filters are delayed until the queryset is executed, so it can account for current get_language() setting if language has been set to None.

Because of the way those two pieces work, it is not possible to apply language filters that depend on some queryset-returning method argument. This is what prevents deep queryset translation (#196) from working: even with keeping track of used tables, as soon as a table is used more than once there is no way to tell.

Restoring queryset.model

Right now, for a TranslatableQueryset, queryset.model is the translation model. It hurts compatibility with several third party modules that expect some custom fields to be present on the model. For instance, MPTT looks for ̀queryset.model._mptt_meta (#246).

Leveraging the new meta API

A lot of transaltionqueryset introspection is still done by having use code dig into some of hvad's internals. The new hvad.utils helper functions are a step towards better encapsulation, but extending Django 1.8's new Meta API to provide documented introspection tools would be much cleaner.

Forbid untranslated instances

An old one from #182: Calling create and friends should always build a translation.

1. Instances with no translation at all break basic assumptions on field access. Up to v0.4, instance.translated_field would raise DoesNotExist or maybe not, depending on current language - now it raises an AttributeError which is cleaner, but this issue remains. It makes very difficult to track bugs.
2. Instances with no translation at all are the reason we have a FallbackQueryset for. Without them everything could be done cleanly on the TranslationQueryset, including language fallbacks, and drop the Fallback mess altogether.
3. Having instances with no translation is already borderline anyway: the FallbackQueryset complains loudly (logger.error) everytime it finds one.
4. Having instances with no translation opens a world of pain for all people that have a custom save on their model or - worse - signal handlers.

Generic queryset

There is not much difference between TranslationQueryset and TranslationAwareQueryset. Except the latter has much older code, is not well tested and lacks more features.
Now we have a smart model navigator that can differentiate models, they could be merged into one queryset, that would work seamlessly with both translatable and regular models.

Admin integration

Not much to do on the technical side here. What would actually be needed would be to get in touch with the team that makes Django's admin app and see whether they would be open to creating some kind of API/interface/hooks so third party apps have better options to override some of its inner working.

While on that, it would also be pretty cool to switch from url-based tabs in the admin to some javascript- based thing for translations. It would make the whole saving process much more intuitive.

[psychok7]

this sounds about right to me.
The admin integration is definitely something that needs some more love (keeping the history of filled inputs when changing to another for example).
Keep up the good work @spectras