Re: [OSCOM] Multilingual Wiki: keeping versions in sync

On Tue, Aug 22, 2006 at 05:36:20PM +0200, Michael Wechner wrote:
> Paul Everitt wrote:

why is this mail not on the list?

> > It would be interesting if someone could conceive (even just page  
> > sketches) a system that had multiple canonicals while retaining  
> > "simple for the civilian".

in an ideal multilingual situation there should be no canonical at all,
because contributors to the content may come from different languages
and should thus all be considered equal.

managing multilingual content could be looked at like revision control
which has two basic operations: add new code, and syncronize code from
others. syncronize code is mostly automatic, while translation is
manual, but the end result is the same: synchronize the content.

so making changes to multilingual content would need to make a
difference between "added new content", or "synchronization of
translation"

like revision control each change should have a version with the highest
version number being the canonical, and a "synchronization" step should
indicate to which version (from which language) it is synchronized
(since you can't always synchronize to the canonical if you do not
understand that language.)

with that information it should be possible to produce a graph that
represents the current state of synchronization and dependency,
indicating where a translation is missing.

just like with revision control adding new content would require
updating to the latest version which.

fixing the canonical to a specific language would be like "read only
access" for the other languages, since they can synchronize, but not add
new content.  this would be like a centralized cvs server

having one translation coming from another would also just be like one
revision control server pulling from another, which would be more like
distributed development.

and making all languages equal is then like the situation where
changesets among the different revision control servers can move in any
direction.

since the problems of distributed development are quite well understood,
and have produced different solutions, i think a lot can be learned from
that.

making this simple for the user should mostly require an interface
that hides the details. most people will only be interrested in a few
languages. when the user initiates an update they will indicate to which
language they want to update to. 

the server should then produce a diff that shows how the content of that
language has changed since the last update (since the server knows the
version of the last update) and if the server uses global version
numbers like subversion, this would even work if the user now updates to
a different language than previously (which should happen very rarely)

so the users won't get an interface much different from existing ones,
as the tricky part is only to figure out what needs updating, where,
which should mostly be doable in the background using the lessons
learned from distributed development.

greetings, martin.
-- 
cooperative communication with sTeam      -     caudium, pike, roxen and unix
offering: programming, training and administration   -  anywhere in the world
--
pike programmer   travelling and working in europe             open-steam.org
unix system-      bahai.or.at                        iaeste.(tuwien.ac|or).at
administrator     (caudium|gotpike).org                          is.schon.org
Martin Bähr       http://www.iaeste.or.at/~mbaehr/