So, I amended the Development policy on meta:
http://meta.wikipedia.org/wiki/Development_policy
...to the effect of: "Document new features in the User's Guide."
Every programmer in the world is too damn busy coding to communicate what they're doing, true. But if you add a feature to MediaWiki, you are the main person who knows about it.
We have a pretty darn good users' and admins' guide now. The more we keep it up-to-date, the better. It's quite easy to add a little bitty wiki page to meta.w.o saying what the feature is and how it works. It doesn't have to be any more complicated than what you put in a changelog summary. Others can then find your features, test em out, expand the doc, etc.
~ESP
Evan Prodromou wrote:
So, I amended the Development policy on meta:
http://meta.wikipedia.org/wiki/Development_policy
...to the effect of: "Document new features in the User's Guide."
Every programmer in the world is too damn busy coding to communicate what they're doing, true. But if you add a feature to MediaWiki, you are the main person who knows about it.
We have a pretty darn good users' and admins' guide now. The more we keep it up-to-date, the better. It's quite easy to add a little bitty wiki page to meta.w.o saying what the feature is and how it works. It doesn't have to be any more complicated than what you put in a changelog summary. Others can then find your features, test em out, expand the doc, etc.
~ESP
Im agree with you.... Im trying to pass from phase 2 to phase 3 and all script code are undocumented too. A good program has a cicle life and documentation is a part of this. When you download mediawiki you have a trivial pursuit install how to. Make this and this other and rest do-it-yourself. If i have a more documented source i will do a better job. :( Brion.....i need help with convertdb.php code....
turismundo:/usr/local/apache/htdocs/phase3/maintenance/archives# php --with-mysql convertdb.php PHP Fatal error: Call to a member function on a non-object in /usr/local/apache/htdocs/nuevo/User.php on line 294 This script is obsolete!It is retained in the source here in case some of its code might be useful for ad-hoc conversion tasks, but it is not maintained and probably won't even work as is.Creating new tables.
perhaps my configure php has fail?
On Mar 11, 2004, at 09:04, Erchache2000 wrote:
Im trying to pass from phase 2 to phase 3 and all script code are undocumented too. A good program has a cicle life and documentation is a part of this. When you download mediawiki you have a trivial pursuit install how to. Make this and this other and rest do-it-yourself. If i have a more documented source i will do a better job. :( Brion.....i need help with convertdb.php code....
It was really not meant to last, that conversion script was a temporary hack. (All temporary things in computers become permanent though, we should learn this. :)
I'd like to try fixing it up, but unfortunately I don't have a phase2 test database to work with. Do you have a dump of the Enciclopedia database that I could download and test with? Otherwise I can try to fix it up blind from the old table declarations.
-- brion vibber (brion @ pobox.com)
"E" == Erchache2000 erchache2000@yahoo.es writes:
E> Im agree with you.... Im trying to pass from phase 2 to phase E> 3 and all script code are undocumented too.
Documenting code is good, too, but I was specifically talking about documenting stuff that non-developers can actually see.
~ESP
Evan Prodromou wrote:
So, I amended the Development policy on meta:
http://meta.wikipedia.org/wiki/Development_policy...to the effect of: "Document new features in the User's Guide."
Every programmer in the world is too damn busy coding to communicate what they're doing, true. But if you add a feature to MediaWiki, you are the main person who knows about it.
Speaking of which. Who made the image thumbnail feature? This feature does not appear to be documented.
And in particular, it still has this bug that [[Image:blah|thumb|''em'']] comes out as <em>em</em> rather than <em>em</em>.
I believe whoever wrote this feature should really fix this, since (as you said) they are bound to be the one who knows the feature best.
Timwi
Timwi-
I believe whoever wrote this feature should really fix this, since (as you said) they are bound to be the one who knows the feature best.
Please always check CVS HEAD first, or at least test.wikipedia.org. Jens has already fixed this bug, and also added the ability to use links and other formatting in captions. This however necessitated some significant code changes, that and other current happenings in the unstable branch mean that it will probably still take a few weeks until these fixes/ features go live.
Regards,
Eirk
Erik Moeller wrote:
Timwi-
I believe whoever wrote this feature should really fix this, since (as you said) they are bound to be the one who knows the feature best.
Please always check CVS HEAD first, or at least test.wikipedia.org.
I have. Both are broken.
Jens has already fixed this bug, and also added the ability to use links and other formatting in captions.
Ah, good to hear. Thanks!
Timwi
Timwi timwi@gmx.net writes:
And in particular, it still has this bug that [[Image:blah|thumb|''em'']] comes out as <em>em</em> rather than <em>em</em>.
Also whitespace handling is dubious. Code as follows may or may not work:
[[Image:blah | thumb | 300px | right | foo]]
Allowing spaces around "|" is important - otherwise lines get too long and horizontal sliders are addding unnecessarily to the edit boxes.
Karl Eichwalder wrote:
Timwi timwi@gmx.net writes:
And in particular, it still has this bug that [[Image:blah|thumb|''em'']] comes out as <em>em</em> rather than <em>em</em>.
Also whitespace handling is dubious. Code as follows may or may not work:
[[Image:blah | thumb | 300px | right | foo]]Allowing spaces around "|" is important - otherwise lines get too long and horizontal sliders are addding unnecessarily to the edit boxes.
To be entirely honest, I don't see that as too much of a problem. If the image name is too long, rename it; if the image caption begins with a very long word, rephrase it...
(of course, for readability's sake, allowing spaces here would be nice)
Timwi
Timwi timwi@gmx.net writes:
Also whitespace handling is dubious. Code as follows may or may not work: [[Image:blah | thumb | 300px | right | foo]] Allowing spaces around "|" is important - otherwise lines get too long and horizontal sliders are addding unnecessarily to the edit boxes.
To be entirely honest, I don't see that as too much of a problem. If the image name is too long, rename it;
1. I like long names a lot. It is not a good idea to upload n-castle-1, n-castle-2, n-castle-3, ... Names should a short description; thus better names will be: nuremberg-castle-palas-s, nuremberg-castle-sinwelltower-n, nuremberg-castle-heavensgate-o, etc.
2. Long names will not be overridden that easily.
3. If you (the WP managers) don't believe in good names just assign randoms letters.
if the image caption begins with a very long word, rephrase it...
Does not help, often the filename is already too long ;)
(of course, for readability's sake, allowing spaces here would be nice)
Exactly.
Karl Eichwalder wrote:
Timwi timwi@gmx.net writes:
To be entirely honest, I don't see that as too much of a problem. If the image name is too long, rename it;
- I like long names a lot. It is not a good idea to upload n-castle-1, n-castle-2, n-castle-3, ... Names should a short description; thus better names will be: nuremberg-castle-palas-s, nuremberg-castle-sinwelltower-n, nuremberg-castle-heavensgate-o, etc.
Sorry, what I really meant was "if the name is a long word".
Instead of "nuremberg-castle-sinwelltower-n", you should really be calling it "Nuremberg Castle Sinwell Tower (1).jpg" (or whatever).
- If you (the WP managers)
I'm not a Wikipedia "manager" (unless you mean sysop, but sysops hardly manage anything, to my knowledge...).
if the image caption begins with a very long word, rephrase it...
Does not help, often the filename is already too long ;)
As I said, make the filename several words.
Timwi
On Sat, 13 Mar 2004, Timwi wrote:
Karl Eichwalder wrote:
- I like long names a lot. It is not a good idea to upload n-castle-1, n-castle-2, n-castle-3, ... Names should a short description; thus better names will be: nuremberg-castle-palas-s, nuremberg-castle-sinwelltower-n, nuremberg-castle-heavensgate-o, etc.
Sorry, what I really meant was "if the name is a long word".
Instead of "nuremberg-castle-sinwelltower-n", you should really be calling it "Nuremberg Castle Sinwell Tower (1).jpg" (or whatever).
I believe that having a file with spaces in its name can cause problems for UNIX-like environments -- which is what I believe the Wikipedia servers run on. Instead of spaces, one should use periods ".", dashes "-" or underbars "_".
(One can work around this aspect of UNIX-like oeprating systems by using quote marks -- but why make things more complex?)
Geoff
On Mar 13, 2004, at 16:15, Geoff Burling wrote:
On Sat, 13 Mar 2004, Timwi wrote:
Instead of "nuremberg-castle-sinwelltower-n", you should really be calling it "Nuremberg Castle Sinwell Tower (1).jpg" (or whatever).
I believe that having a file with spaces in its name can cause problems for UNIX-like environments -- which is what I believe the Wikipedia servers run on. Instead of spaces, one should use periods ".", dashes "-" or underbars "_".
Spaces are fine in UNIX, however the wiki transforms spaces into underscores (and vice-versa).
If you upload "Nuremberg Castle Sinwell Tower (1).jpg" you'll get "Nuremberg_Castle_Sinwell_Tower_(1).jpg", and a link [[Image:Nuremberg Castle Sinwell Tower (1).jpg]] will work just fine.
-- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
"GB" == Geoff Burling llywrch@agora.rdrop.com writes:
GB> I believe that having a file with spaces in its name can cause GB> problems for UNIX-like environments -- which is what I believe GB> the Wikipedia servers run on. Instead of spaces, one should GB> use periods ".", dashes "-" or underbars "_".
GB> (One can work around this aspect of UNIX-like oeprating GB> systems by using quote marks -- but why make things more GB> complex?)
So, it's not Unix-likes but the Web that doesn't allow spaces. You're not supposed to put spaces in an URL. (Some browsers will retrieve an URL with spaces in it, but you're still not _supposed_ to.)
~ESP
- -- Evan Prodromou evan@wikitravel.org Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide
Evan Prodromou wrote:
So, it's not Unix-likes but the Web that doesn't allow spaces. You're not supposed to put spaces in an URL. (Some browsers will retrieve an URL with spaces in it, but you're still not _supposed_ to.)
No browser will retrieve a URL with a space in it. It will either replace it with "+" or "%20". And in fact, every browsers should really be doing that, because this is the standard way of encoding characters that are normally not allowed in URLs.
Timwi
On Mar 14, 2004, at 19:03, Timwi wrote:
Evan Prodromou wrote:
So, it's not Unix-likes but the Web that doesn't allow spaces. You're not supposed to put spaces in an URL. (Some browsers will retrieve an URL with spaces in it, but you're still not _supposed_ to.)
No browser will retrieve a URL with a space in it. It will either replace it with "+" or "%20". And in fact, every browsers should really be doing that, because this is the standard way of encoding characters that are normally not allowed in URLs.
For those in the audience who may not be familiar with HTTP: when you fetch a page over HTTP, you open a channel to the server and then ask it like this:
GET /wiki/Some_page HTTP/1.1 Host: en.wikipedia.org
If you tried to put a raw space in there, you'd produce an invalid request:
GET /wiki/Some page HTTP/1.1 Host: en.wikipedia.org
Apache will reject it with a '400 Bad Request' error, while Squid seems to try to take out the spaces and pass on a "fixed" URL.
Netscape 4.x will actually produce that invalid request when told to follow a URL with a raw space in it. Most current browsers though know that you didn't _mean_ to ask for a space, and before sending it on to the server will automatically transform the requested URL with the escape sequence for space, %20:
GET /wiki/Some%20page HTTP/1.1 Host: en.wikipedia.org
A URL that's meant to contain an embedded space should use the %20 to begin with, and our wiki does escape the URLs it uses. (Besides which we replace spaces in titles with underscores for historical compatibility and attractiveness compared to "%20".)
-- brion vibber (brion @ pobox.com)
On Sun, 14 Mar 2004, Evan Prodromou wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
"GB" == Geoff Burling llywrch@agora.rdrop.com writes:
GB> I believe that having a file with spaces in its name can cause GB> problems for UNIX-like environments -- which is what I believe GB> the Wikipedia servers run on. Instead of spaces, one should GB> use periods ".", dashes "-" or underbars "_". GB> (One can work around this aspect of UNIX-like oeprating GB> systems by using quote marks -- but why make things more GB> complex?)So, it's not Unix-likes but the Web that doesn't allow spaces. You're not supposed to put spaces in an URL. (Some browsers will retrieve an URL with spaces in it, but you're still not _supposed_ to.)
No, as Brion & Timwi noted, the problem really doesn't lie with the Web, but with Unix-like OS's (with the possible exception of OS X); UNIX interprets a raw space as a separator, so that if you try to manipulate a file with a space in it (say, "An example file.txt"), the OS will split the file name on the spaces & assume you are trying to manipulate several files (in the case of the example, the files would be "An", "example", & "file.txt").
There are ways around this -- quoting, using find with the -inum switch, etc. -- that one picks up fairly early in learning Unix. Unfortunately, most scripts are written on the fly, & don't always test for possible errors like this; avoiding spaces in file names is just a good habit to adopt. (I am glad to learn Squid does address this issue.)
Geoff
On Mar 15, 2004, at 09:36, Geoff Burling wrote:
No, as Brion & Timwi noted, the problem really doesn't lie with the Web, but with Unix-like OS's (with the possible exception of OS X); UNIX interprets a raw space as a separator,
No. As I noted, UNIX has no problem with spaces at all.
The HTTP protocol explicitly excludes a raw space character from URLs. Period.
so that if you try to manipulate a file with a space in it (say, "An example file.txt"), the OS will split the file name on the spaces & assume you are trying to manipulate several files (in the case of the example, the files would be "An", "example", & "file.txt").
That is incorrect. A filename on UNIX may contain spaces with no problem.
There are ways around this -- quoting, using find with the -inum switch, etc. -- that one picks up fairly early in learning Unix. Unfortunately, most scripts are written on the fly, & don't always test for possible errors like this; avoiding spaces in file names is just a good habit to adopt. (I am glad to learn Squid does address this issue.)
These are not issues with the OS, but with command-line shells. From an actual program you can sling spaces around all you please.
-- brion vibber (brion @ pobox.com)
On Mar 15, 2004, at 09:36, Geoff Burling wrote:
(I am glad to learn Squid does address this issue.)
Squid does the wrong thing, actually; it *removes* the spaces rather than *replacing* them with escaped versions. Ask for "Foo bar" and you get "Foobar" instead of "Foo%20bar".
-- brion vibber (brion @ pobox.com)
On Mon, 15 Mar 2004 09:56:50 -0800, Brion Vibber wrote:
On Mar 15, 2004, at 09:36, Geoff Burling wrote:
(I am glad to learn Squid does address this issue.)
Squid does the wrong thing, actually; it *removes* the spaces rather than *replacing* them with escaped versions. Ask for "Foo bar" and you get "Foobar" instead of "Foo%20bar".
I think there's a compile option (or was it a patch?) available that inserts an unscore instead, but that's just from memory.
Timwi timwi@gmx.net writes:
Instead of "nuremberg-castle-sinwelltower-n", you should really be calling it "Nuremberg Castle Sinwell Tower (1).jpg" (or whatever).
The 'n' is short for 'north' ;)
Geoff Burling llywrch@agora.rdrop.com writes:
I believe that having a file with spaces in its name can cause problems for UNIX-like environments -- which is what I believe the Wikipedia servers run on. Instead of spaces, one should use periods ".", dashes "-" or underbars "_".
Yes, I still do not believe in filenames with spaces.
(One can work around this aspect of UNIX-like oeprating systems by using quote marks -- but why make things more complex?)
Yes, that's usually my reasoning. Maybe, I should start chaning my mind.
Brion Vibber brion@pobox.com writes:
Spaces are fine in UNIX, however the wiki transforms spaces into underscores (and vice-versa).
If you upload "Nuremberg Castle Sinwell Tower (1).jpg" you'll get "Nuremberg_Castle_Sinwell_Tower_(1).jpg", and a link [[Image:Nuremberg Castle Sinwell Tower (1).jpg]] will work just fine.
This all is interesting and encouraging. Only the suffix part ".jpg" does not look nice.
Karl Eichwalder ke@gnu.franken.de writes:
Yes, that's usually my reasoning. Maybe, I should start chaning my mind.
For some reason, uploading "grossgruendlach rathaus kirchturmsonnenuhr v s.jpg" to the german WP via a moderately modified version of pywikipedia/upload.py didn't work. This filename worked: grossgruendlach-rathaus-kirchturmsonnenuhr-v-s.jpg.
[CC'd to pywikipediabot-users list]
On Mar 14, 2004, at 01:18, Karl Eichwalder wrote:
For some reason, uploading "grossgruendlach rathaus kirchturmsonnenuhr v s.jpg" to the german WP via a moderately modified version of pywikipedia/upload.py didn't work. This filename worked: grossgruendlach-rathaus-kirchturmsonnenuhr-v-s.jpg.
When given spaces, the upload form stops to warn you that it's changing the filename and requires a confirmation. (Which is kind of annoying.) I haven't checked, but the bot may not handle that case.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
[CC'd to pywikipediabot-users list]
On Mar 14, 2004, at 01:18, Karl Eichwalder wrote:
For some reason, uploading "grossgruendlach rathaus kirchturmsonnenuhr v s.jpg" to the german WP via a moderately modified version of pywikipedia/upload.py didn't work. This filename worked: grossgruendlach-rathaus-kirchturmsonnenuhr-v-s.jpg.
When given spaces, the upload form stops to warn you that it's changing the filename and requires a confirmation. (Which is kind of annoying.) I haven't checked, but the bot may not handle that case.
This is indeed something I had not encountered yet, it should handle it now.
Rob
Rob Hooft rob@hooft.net writes:
This is indeed something I had not encountered yet, it should handle it now.
Thanks, now it is working.
I added support for uploading a bunch of images: upload.py will read filenames and descriptions from a file name job.txt, every record is finished with the marker -=- . My code isn't generic enough to be useful, I guess:
def main(): import urllib,os fn = "job.txt" start = 1 text = '' if os.path.exists(fn): f=open(fn) for line in f.readlines(): if line == "-=-\n":
file = urllib.urlopen(img) contents = file.read() file.close() # Isolate the pure name if '/' in img: img = img.split('/')[-1]
if '\' in fn: img = img.split('\')[-1] print "The filename on wikipedia will default to:",img # Wikipedia doesn't allow spaces in the file name. # Replace them here to avoid an extra confirmation form img = img.replace(' ', '_')
description = text
data = post_multipart(wikipedia.langs[wikipedia.mylang], uploadaddr, (('wpUploadDescription', description), ('wpUploadAffirm', '1'), ('wpUpload','upload bestand')), (('wpUploadFile',img,contents),) )
start = 1 text = '' continue
if start: img = line start = False continue
text = text + line
return fn
And job.txt looks this way:
/path/to/images/2003-11-16/grossgruendlach schloss ansicht v nw.jpg ;Beschreibung: [[Großgründlach]], stadtteil von [[Nürnberg]], schloß, ansicht von wn (2003-11-16). ;Quelle: Fotographie 2003-11-16 ;Fotograph: --~~~ ;Copyright Status: [[GNU Freie Dokumentationslizenz]]
Im hintergrund die kirche.
Weitere bilder dieses objekts: [[:bild:grossgruendlach schloss ansicht v so.jpg]]
-=-
On Thu, Mar 11, 2004 at 11:42:31PM +0000, Timwi wrote:
Evan Prodromou wrote:
So, I amended the Development policy on meta:
http://meta.wikipedia.org/wiki/Development_policy
...to the effect of: "Document new features in the User's Guide."
Every programmer in the world is too damn busy coding to communicate what they're doing, true. But if you add a feature to MediaWiki, you are the main person who knows about it.
Speaking of which. Who made the image thumbnail feature? This feature does not appear to be documented.
Me. The documentation is at http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax
But as I think Evan is right, documentation should become part of the users guide, I've included that page into http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide:_Adding_multimedia
And in particular, it still has this bug that [[Image:blah|thumb|''em'']] comes out as <em>em</em> rather than <em>em</em>.
I believe whoever wrote this feature should really fix this, since (as you said) they are bound to be the one who knows the feature best.
As mentioned before, it's fixed. It will even allow [[Image:blah|thumb|An image of a ''beautiful'' [[Blah]], seen in the [[zoo]].]]
Best regards,
JeLuF
Jens Frank wrote:
On Thu, Mar 11, 2004 at 11:42:31PM +0000, Timwi wrote:
Speaking of which. Who made the image thumbnail feature? This feature does not appear to be documented.
Me. The documentation is at http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax
But as I think Evan is right, documentation should become part of the users guide, I've included that page into http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide:_Adding_multimedia
Who will look for it under "multimedia"? Please make it something that contains either "image" or "thumb". :-p
I believe whoever wrote this feature should really fix this [...].
As mentioned before, it's fixed.
Thanks a lot! :-) I'm looking forward to it going live, then.
Timwi
wikitech-l@lists.wikimedia.org