DEP django model internalization feedback

[Ashley Camba Garrido]

This is rough draft of something that I have been playing around with, with the help of anssi.

Tinkering around it seems that you can implement most of this with barely touching django,

or at least without breaking backward compatibility. Some of the major issues are almost philosophical :)

Specially the part about handling migrations caused by apps on tables that don't belong to them and stuff like that.

Before I follow this route I wouldn't mind getting some feedback.

Cheers,

ash

[Ashley Camba Garrido]

Damn, forgot the link.

https://github.com/ashwoods/deps/blob/master/draft/xxxx-model-internalization.rst

[Carl Meyer]

Hello,

On 06/28/2015 08:04 AM, Ashley Camba Garrido wrote:
> Damn, forgot the link.
>
> https://github.com/ashwoods/deps/blob/master/draft/xxxx-model-internalization.rst

I think the DEP is well-motivated; thanks for picking up this topic.
This is a problem that would be useful to have some standardized
approach for in core, because of the third-party-models issues you
mention in the DEP, and the ugly monkeypatching generally required to
implement translatable models.

The implementation section of your DEP is obviously very preliminary
still. Here's what I think would be required for an accepted DEP in this
area (and yes, this will be a lot of work):

- Review of the commonly-used third-party packages implementing model
translation (e.g. the top three or four from
https://www.djangopackages.com/grids/g/model-translation/), comparing
their API and implementation strategy, with examples.

- Discussion of the range of differing needs around model translation
(e.g. some sites have many languages and add languages frequently,
others have a small fixed set of languages; these situations lend
themselves to preferring different implementations).

- Based on the above, a proposed model-translation-backend API that can
support these different needs; ideally one which would allow for any of
the popular implementation strategies (unless you can make a case that
some strategy is strictly inferior in all cases and does not need to be
supported.)

- A working proof-of-concept implementation of this backend API, with at
least two working backends implemented that use different strategies for
storing and loading translations.

I think you could look at the (accepted in 1.8) template backends DEP
(https://github.com/django/deps/blob/master/accepted/0182-multiple-template-engines.rst)
for a good example of the level of detail and comprehensiveness you
would need to achieve in your DEP before proposing it for acceptance.

You should also review the DEP process:
https://github.com/django/deps/blob/master/final/0001-dep-process.rst#pre-proposal

I think your idea is a good DEP candidate, which means you've completed
the first step (pre-proposal). One of the next steps will be to find a
core developer who is willing to fill the Shepherd role (primary
reviewer). I will consider whether I could do this, but I'm not sure.

Good luck, and thanks for the proposal!

Carl