On Sun, 16 Jan 2005 03:37:39 +1100, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Then why, to pick an example, is there no second or third show/hide link in the header of RC in a default installation of de, fa, lt, ro, th or wa? It's been 11 months since I implemented that feature. They don't propagate, we need a way to flag messages needing translation.
We do indeed. I have a friend who is part of the Welsh translation team for GNOME, and they have all sorts of automated statistics telling them what is unfinished, out of date, etc. I'm sure there are tools out there somewhere which we could adapt to our needs.
Or maybe a home-grown system is enough - basically, a database or somesuch with the following fields: * Language * Release (so that, for instance, 1.3.x and 1.4.x can both have appropriate translations) * Message name * Last translated (if we assume that En will always be the master, we can just compare <date of last change to En> with <date of last change in this language> to see if the message is up to date)
From this, we can produce pretty graphs like GNOME does
(http://l10n-status.gnome.org/gnome-2.10/index.html) so people can see just how far their language is lagging behind, and which messages it is that have changed/been added.
Add to this some kind of web interface for doing the translations themselves, to replace the "run a wiki and export the MediaWiki: namespace occasionally" habit, and ... yes, I know, "so code it then, Rowan". Maybe I should... [it's possible, but I doubt I will].
Of course, we'd then need anyone who checks in a patch that affects the meaning or function of a message, even if the English message can stay the same, to reset the timestamp on the En entry; but if we forced them through the translation interface too, I guess this would happen when things did change, anyway.
Oh, and then there's the problem of individual wikis having editted their MediaWiki: pages, and so needing to merge their changes with those of a new software version when it's finally released. We need to notify them of that somehow, too. [Although, come to that, users need somewhere to notify a sysop that a message needs changing *anyway*...]
But maybe I should stop dreaming now!