That was the only point in that cur_old where a timestamp does not match with the inverse timestamp. I addionally checked if there is a timestamp which is older than the first one (200105xxxx). But there was none. There is another thing I do not understand. I assumed that the timestamps should be sorted. Nearly that is true. But often there are some timestamps which are much smaller (more than month!) than the others around? Whats the reason for that? Thanks! Could'n we change that? It should be easy to change all "*" appearing before the change to the new software. Or is there a good reason for don't doing that. Since the username should be almost always the same before the conversion and after it we could change each old id (set to zero know) to the new id after the change to the new software. Since we should have a list of all user-ids and the coresponding user_names we could change all 0-id before convertion to the new id if the user_name matches?! Ok, but it even contains 68 times "0" in the german old_cur and is empty in all others. Could that zeros be changed to ""? --Ivo Köthnig

What do you think about force user to choose a licence (in a combo box) when uploading a media (pictures, sound, etc.) to Wikipedia. I see 2 benefits: * Force user to care about licence, * Automatically add {{msg:<NameOfLicence>}} to the bottom of media description page. Aoineko Example: ---------------------- | Choose a licence |v| ---------------------- | GFDL | | Public Domain | | Fair Use | | ... | --------------------

Evan Prodromou wrote: Thanks it's exactely what we need. Alas, now uploading doesn't work anymore on fr: Can someone look at this, please? -- Looxix

I'm not sure what exactly this all means, but I am hopeful that it will mean something to someone else... I've just finished doing some "repair" work on [[wikipedia:Orphaned Articles]]. I had to remove multiple repeated segments of the page. I say "segments" because they did not directly correspond with sections. Multiple sections were repeated as a group, though it did seem to be on section boundaries. Either someone was extraordinarily careless (or deliberately disruptive), or somehow the data got mashed together incorrectly. (probably in the database?) I did not compare the repeated segments to verify that they matched, so some changes could have been lost (not a huge issue with this page -- just some extra work). However, it did not seem to over-write data, just sort of append them together in strange ways. My main concern is that this could be happening to other pages where loss of changes could be much more significant. Is this a known bug? Something to do with edit conflicts that are not handled correctly? -Rich Holton ([[User:Rholton]]) __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

--- Timwi &lt;timwi(a)gmx.net&gt; wrote: Ahhh! Mea culpa! If this reply isn't correct, I'll have to sign up for remedial training. http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Orphaned_articles&… Ummm... [[wikipedia:Orphaned Articles]] is distinct from [[wikipedia:Orphaned articles]] (look closely). I understand the need for, but still hate, case sensitivity. Yeah, a valid criticism of my description (but it was perfectly clear to ME what I meant! ;) Now that my mind is clearer (and I've been properly chastised for my vagueness), I can report the following: It does sound similar to what you describe, though more muddled. Here we had: -Heading plus sections A & B -Heading -Heading plus sections A thru Z (ie whole correct page) -Sections D thru Z Fortunately, I came along only three changes past where the corruption occurred, and all the changes were made to the part that corresponded to the whole correct page, which is what I retained. So nothing was lost, as it turns out. By the way, kudos to whoever conceived of and implemented the comparison-between-arbitrary-versions feature. Looking at the page history, it's clear that the corruption was introduced when someone attempted to submit the same change three times in a row -- probably because of an apparent lack of response. Still my main concern. Thanks for your attention to this, Timwi. I do tend to forget the power of the revision history. Obviously, any loss could be recovered, but the work required to do so could be truly significant, depending upon the page in question, the nature of the corruption, and how many additional revisions happened between the corruption and its detection. Again, thanks for your attention. I hope I've made a clearer report. I no longer see this to be particularly urgent, but I still consider it to be important. -Rich Holton __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com