I wasn't involved in the initial development of the translatable
system, Ingo had much more to do with it. Unfortunately, he is on
leave for 4 weeks! :-S
However, I think we can probably still have a fruitful discussion
about this. The model for Translatable was Versioned. I think that
the data model for Versioned has generally been pretty successful, and
I think that the use-cases of Translatable are sufficiently similar
for that to be a good justification for the current Translatable data-
model.
I think that my general thinking is that Translatable is definitely a
little rough around the edges and in need of some love, but I don't
think that changing the data model is going to fix the most important
problems.
Your approach could have merit; that is the way that we attacked the
subsites module. However, the difference between subsite module and
the translatable module is that translatable has a much stronger tie
between versions of the same page in different languages. We have
struggled with that a bit in subsites - one can do it but we keep
running into bugs.
One thing that irks me a little is the fact that Translatable is so
heavily baked into the core. I would like to see Translatable spun
out as an add-on module. If we did that, then there would be more
room to experiment with alternative Translatable implementations.
Although I think that would have to be "experiment" in the sense of
"try a couple of alternatives and then determine a winner" rather than
"support 2 translatable implementations in the long term". ;-)
I would, however, prefer to look at debugging the Translatable model
with its existing data model before radically changing it. It would
also be good to increase the test coverage of the current Translatable
system; this will make it much less risky to muck with the internals
in the way that you describe.
> Let me focus on the extending of DataObjects. As far as I can tell the only
> way to provide support for it will be to create a DataObject_lang table for
> each and every subclass (with a table),
Adding tables is cheap; so I don't see the fact that there are
additional tables as a significant issue.
> not only that, but the translatable
> fields for all subclasses will always need to be defined when the extension
> is applied.
This is a bigger issue. In general, we need to avoid situations where
the order that extensions are applied matters. The way to address
this issue would be to call loadExtraDBFields() on every extension and
then call augmentDatabase() on every extension. It looks like the
current implementation is structured in this way, so I'm not sure what
the problems are there.
I agree with what you say about using a blacklist rather than a
whitelist.