From a non-techie point of view, I think it is more
important to relate a translation to the content item
than to its versions, since translators will probably
not want to translate each version again but rather
adapt the changes incrementally (unless they do it
automatically, which guarantees poor quality, or have
it done by companies paid for line counts, which
guarantees high cost).
The distinction made above between different translation
paths ("localizaton" vs. "translation") will, IMO, be more
important to the administrators of new versions and
translations than to the reader, and the terminology
is confusing since incorrect: Localizaton is not the
end product of a translation process but may be more,
including, for instance, replacing a red cross by a red
(or green?) half-moon.
I am surprised how much effort is invested in determining
automated ways to have dotLRN present a localized page
rather than (a) let the user's browser settings negotiate
the language (does AOLserver support Apache's multiview
method at all?), and (b) let the user decide explicitely.
Especially when current quality translations are not
available, the locale setting selected for the UI need not
at all be the optimal choice for reading complicated texts.
