Wikitech-l December 2008

wikitech-l@lists.wikimedia.org

89 participants
67 discussions

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

Replacement stats for placeholder images?
by David Gerard 13 Oct '09

13 Oct '09

I've been putting placeholder images on a lot of articles on en:wp. e.g. [[Image:Replace this image male.svg]], which goes to [[Wikipedia:Fromowner]], which asks people to upload an image if they own one. I know it's inspired people to add free content images to articles in several cases. What I'm interested in is numbers. So what I'd need is a list of edits where one of the SVGs that redirects to [[Wikipedia:Fromowner]] is replaced with an image. (Checking which of those are actually free images can come next.) Is there a tolerably easy way to get this info from a dump? Any Wikipedia statistics fans who think this'd be easy? (If the placeholders do work, then it'd also be useful convincing some wikiprojects to encourage the things. Not that there's ownership of articles on en:wp, of *course* ...) - d.

7 11

en.wiki migrated to new search backend
by Robert Stojnic 06 Jun '09

06 Jun '09

Hi all, We now have english wikipedia fully migrated to new servers / new search backend. We cannot fully migrate other wikis until we resolve some hardware issues. In the meantime, here is the overview of new features now deployed on en.wiki: 1) Did you mean... - we now have search suggestions. Care has been taken to provide suggestions that are context-sensitive, i.e. on phrases, proper names, etc.. 2) fuzzy and wildcard queries - a word can be made fuzzy by adding ~ to it's end, e.g. query sarah~ thompson~ will give all different spellings and similar names to sarah thompson. Wildcards can now be prefix and suffix, e.g. *stan will give various countries in central asia. 3) prefix: - using this magic prefix, queries can be limited to pages beginning with certain prefix. E.g. mwsuggest prefix:Wikipedia:Village Pump will search all village pumps and archives for mwsuggest. This should be especially useful for archive searching in concert with inputbox or searchbox 4) intitle: - using this magic prefix, queries can be limited to titles only 5) generally improved quality of search results via usage of related articles (based on co-occurrence of links), anchor text, text abstracts, proximity within articles, sections, redirects, improved stemming and such Cheers, Robert

6 7

new extension for embedded music scores
by River Tarnell 24 May '09

24 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello, i have written a new extension to embed music scores in MediaWiki pages: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:ABC unlike the Lilypond extension, this uses a simple input language (ABC) that is much easier to validate for security. ABC is mostly used to transcribe Irish trad and other simple tunes, but it recently gained support for more advanced features, e.g. multiple staves and lyrics. this is supported in the extension using the 'abcm2ps' tool. unlike the existing ABC extension (AbcMusic), it doesn't support opening arbitrary files as ABC input (which is a potential security issue), and has several additional features: - - The original ABC can be downloaded easily - - The score can be downloaded as PDF, PostScript, MIDI or Ogg Vorbis - - A media player can be embedded in the page to play the media file i believe the ABC format is suitable for transcribing the majority of scores currently on Wikimedia projects. although it can't handle all of them, it is better than the current situation. plus, as ABC is simple, and existing ABC scores are easily available, it's easier for novice users to contribute. i would be interested to hear peoples' thoughts on enabling this extension on Wikimedia. - river. -----BEGIN PGP SIGNATURE----- iD8DBQFJBwL+IXd7fCuc5vIRAqG6AJ9RxKTGjJ7ywdZoesrTJWrMPtBYrACgjgDX lIY552ilDFaVG1mLzqW1F/Y= =7Tda -----END PGP SIGNATURE-----

14 24

Open Document Format
by Lars Aronsson 18 May '09

18 May '09

Can someone explain why the Wikimedia Commons accepts uploads of printable PDF documents (e.g. brochures) but not the editable source version in Open Document Format (e.g. .ODT). This seems to violate the open source principle. This should be an FAQ but, but it isn't obvious from http://commons.wikimedia.org/wiki/Commons:File_types -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

11 25

On extension SVN revisions in Special:Version
by Brion Vibber 29 Apr '09

29 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Special:Version displays SVN version numbers for extensions out of $wgExtensionCredits, which seems to be done with $LastChangedRevision$ keywords in the extension's entry point file. This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected. If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki. But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful. Anybody have a suggestion on how to best handle this? - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklb6VcACgkQwRnhpk1wk44MNACg2c0ztpocjHfsb5l+KxSu8e+I wXgAoMSrjFeTPzEnMY4904bxXZv+DiYf =GNqG -----END PGP SIGNATURE-----

9 24

Re: [Wikitech-l] The never-dying topic: category intersection
by Aerik Sylvan 31 Jan '09

31 Jan '09

On Wed, 03 Dec 2008 16:48:39 +0100, Roan Kattouw <roan.kattouw(a)home.nl > wrote: > > We had a pretty lengthy discussion about this before the summer, and the > consensus seemed to be that a fulltext-based approach looked most > viable. I actually wrote an extension that does that, and promised to > release it soon; that was quite a few months ago, and I never got around > to it. I'll release it properly when I have time, which will hopefully > be before Christmas :D > > The code needs some tweaking and refactoring, though. It's pretty > tightly integrated with the article text search (both functions in one > form) and has all kinds of weird features, because the guy who paid me > to write it wanted them. It also doesn't support three-letter word > searching (which core does these days, using a prefix hack), which is > pretty bad since categories with short titles (or stopword titles) won't > be found either. > > Roan Kattouw (Catrope) > > Hey Roan, does your code use the a new table for the category search (with fulltext index) and do you have the hooks for maintaining that table? Do you display the the results on a new search results page, or did you hack the existing one? Basically, I'm thinking that even if your stuff isn't ready for prime time, you may have already done a lot of the heavy lifting... can we get our hands on it? Thanks! Aerik -- http://eventfeed.org - An Initiative Promoting Syndication of Events http://www.wikidweb.com - the Wiki Directory of the Web http://tagthis.info - Hosted Tagging for your website!

5 7

License information (was: PDF/Collection feature live on de.wikibooks)
by Johannes Beigel 30 Jan '09

30 Jan '09

Am 10.10.2008 um 21:22 schrieb Erik Moeller: > 2008/10/10 Derbeth <derbeth(a)wp.pl>: >> I wonder about the legal aspects. In my opinion, when you create a >> ready-to-print version, >> you have to attach the text of GFDL license to it - directly, not >> as a link. Like it is done in >> http://en.wikibooks.org/wiki/Image:LaTeX.pdf. As Erik wrote: This is already implemented (either a title of an article or a URL to some license text can be set in LocalSettings.php), but it's currently not configured. >> Secondly, current version of the tool does a plagiarism - beacause >> it does not mention >> image authors and does not provide any mean (like by making images >> clickable) to check >> these authors. > > Ouch, thanks for pointing that out. Tricky to do this automatically > since it's all wiki-text with templates, but we'll investigate a > solution here. We'd highly appreciate input from the community regarding this topic! The printed books from PediaPress contain a list of figures where the license of each image is listed, together with the URL to the image description page. As some kind of "hotfix" this solution could be implemented in the PDF export of the Collection extension, too. But this doesn't really solve the problem. We think it's more of a technical/software thing, so I cross-posted (and set Reply-To) to Wikitech-l. In our opinion, license management/handling must be a core feature of MediaWiki, because the software is explicitely developed for the collaborative distribution of free content. Licenses of the containing articles and images should not be represented via some agreed-upon convention but via structured (and machine-readable) information, available for each relevant object in the wiki. Some information that would be desired: - Full (official) name of the license(s). - Whether the full text of the license has to be included or a reference sufficient. - Reference to the full text of the license(s) (in some rigidly defined format like wikitext). - Whether attribution is required. If so: The list of required attributions. So, basically all the information that's required to check if it's possible to take some part of the MediaWiki and use it somewhere else and all the information that has to be included in that other place. This information could be made accessible via MediaWiki API, but ideally it's contained in the wikitext and/or XHTML, too. All this could be handled via microformats, even inside of templates, but the main point is that any kind of new technique has to be enforced, ideally via MediaWiki software itself: In the commons wikis there are some conventions that can be used in software by people/ companies like us (although we have to work with hacks and workarounds), but oftentimes, in wikis with smaller communities this information doesn't even exist at all. -- Johannes Beigel

5 10

Section anchor encoding
by Brion Vibber 05 Jan '09

05 Jan '09

[Breaking this thread off...] On 12/28/08 1:32 AM, Niklas Laxström wrote: > The anchors of non-latin headers are already (latin) gibberish: > #.D0.A4.D0.B8.D0.BB.D1.8C.D0.BC.D0.BE.D0.B3.D1.80.D0.B0.D1.84.D0.B8.D1.8F > > It doesn't seem reasonable to think that people could create anchors > in their head from text, except in special cases. If we're going to stick with strict ASCII-limited anchors, it might be worth considering making them more legible, say with transliteration to ASCII Latin chars. :P On the other hand, XHTML *doesn't* actually limit us this way! The XHTML 1.0 recommendation of restriction to [A-Za-z][A-Za-z0-9:_.-]* is for compatibility with HTML 4.0, which defines: ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). XHTML specifcies ID and NMTOKEN types here, which are *not* restricted to ASCII, but rather a large number of scripts: http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-NameChar http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Letter http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Digit http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Extender If there are no major browser compatibility problems, I would probably recommend we roll back the nasty old .XX encoding for HTML 4 compatibility, in which case we could quite legally produce something direct, such as: http://ru.wikipedia.org/wiki/Уплисцихе#Уплисцихе_в_средневековье which URL-encodes out to: http://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D0%BB%D0%B8%D1%81%D1%86%D0%B8%D1%… (which can be nicely displayed as pretty Unicode in the URL bar of modern browsers) as opposed to the current: http://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D0%BB%D0%B8%D1%81%D1%86%D0%B8%D1%… -- brion

2 7

Subpage titles
by Michael J. Walsh 05 Jan '09

05 Jan '09

This is a proposal to change how the MediaWiki software displays subpages. This isn't really an issue over a Wikipedia because subpages in the main namespace are disabled, but using subpages at Wikisource is a standard way of dividing up works, leaving only a table of contents at the root article. The problem is that this results in pages titles like this: United States Code/Title 35/Chapter 14/Section 151 or even Nicene and Post-Nicene Fathers: Series II/Volume I/Constantine/The Life of Constantine/Book II/Chapter 23 which IMHO looks more like a file system than a user-friendly website. I would suggest United States Code » Title 35 » Chapter 14 » Section 151 or my own favourite United States Code » Title 35 » Chapter 14 » Section 151 (With "Section 151" in bigger font.) This would effectively involve moving the subpages div above the title and changing the title from the entire path to just the subpage name. See: http://en.wikisource.org/wiki/Wikisource:Scriptorium#Subpage_formatting for the discussion I started on Wikisource and further down the same page http://en.wikisource.org/wiki/ Wikisource:Scriptorium#Subpage_formatting:_some_more_examples for some formatted versions of the above examples and http://en.wikisource.org/wiki/Nicene_and_Post- Nicene_Fathers:_Series_II/Volume_I/Constantine/ The_Life_of_Constantine/Book_II/Chapter_23 and http://en.wikisource.org/wiki/Treaty_on_European_Union/ Protocol_on_the_convergence_criteria_referred_to_in_Article_109j_of_the_ Treaty_establishing_the_European_Community for examples of how ugly the current setup can be. Michael

8 18

Deprecate 'sysop' throughout MediaWiki?
by MZMcBride 02 Jan '09

02 Jan '09

There's been a bit of recent discussion about deprecating the term 'sysop' throughout MediaWiki by replacing it with 'admin' or 'administrator'. The primary advantage here would be that 'admin' or 'administrator' is more clear and better defines the role that these users play within a wiki. See also related bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=16737 There are a number of different places that 'sysop' is used throughout the software, and it may or may not be advantageous to change all of them (for example inside the user_groups table). On the other hand, however, changing only some of the software while not changing other parts may simply lead to more confusion. Thoughts on the idea in general? Thoughts on the details? MZMcBride public(a)mzmcbride.com

9 8

String truncation and ellipses
by Brion Vibber 31 Dec '08

31 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Raymond recently added an 'ellipsis-separator' message to core (which I've changed to simply 'ellipsis') defaulting to the Unicode ellipsis character "…", which is so far only used in the Lucene search plugin when building text snippets. I took a quick look around at calls to $*lang->truncate() and found that nearly all of them pass an explicit '...' $ellipsis parameter, overriding the default which is to do a straight truncation at the cutoff. [ Fun fact: "..." (three ASCII full-stops) and "…" (Unicode ellipsis) both take 3 bytes in UTF-8! :D ] Is there any objection to changing Language::truncate() to default to using the language-appropriate 'ellipsis' message (content message when calling on $wgContLang, UI message when calling on $wgLang)? This would certainly be simpler than adding wfMsg() calls on all of them. :) Callers really wanting straight truncation without a pretty ellipsis could still pass '' explicitly. One downside is that extensions using the new call format assuming the ellipsis as default would not get an ellipsis when used on older MediaWiki versions. (Boo-hoo!) - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklb3LEACgkQwRnhpk1wk473iACfcTON8Ae8LATR8Z+vZ6qAxRWO h/cAoJH6mU1opFnYPzjstNyp6bDBv/3I =l1E/ -----END PGP SIGNATURE-----

1 0

Re: [Wikitech-l] Wikitech-l Digest, Vol 65, Issue 40
by Ján Uličný 31 Dec '08

31 Dec '08

HELP...HELP...SOS...nerozumiem reči vážho kmena,dostal som od vás 5správ ale neviem čo je tam napisané,lebo nerozumiem Vašej reči či jazyku.Ja som slovák,SLOVENSKO(szecho-slovakia)ahojte bratia Dabačovci-píšte mi po slovenský,JA VAS NEPANIMAJU-ZDRASTVUJTE.... ______________________________________________________________ > Od: wikitech-l-request(a)lists.wikimedia.org > Komu: wikitech-l(a)lists.wikimedia.org > Datum: 31.12.2008 06:33 > Předmět: Wikitech-l Digest, Vol 65, Issue 40 > >Send Wikitech-l mailing list submissions to > wikitech-l(a)lists.wikimedia.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >or, via email, send a message with subject or body 'help' to > wikitech-l-request(a)lists.wikimedia.org > >You can reach the person managing the list at > wikitech-l-owner(a)lists.wikimedia.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Wikitech-l digest..." > > >Today's Topics: > > 1. Re: Subpage titles (Remember the dot) > 2. Re: Anchors haven't id attribute (Platonides) > 3. Re: Separating section anchors from other IDs (was: Anchors > haven't id attribute) (Charlotte Webb) > 4. Re: Subpage titles (Aryeh Gregor) > 5. Re: Subpage titles (Platonides) > 6. Re: Separating section anchors from other IDs (was: Anchors > haven't id attribute) (Aryeh Gregor) > 7. Re: Subpage titles (Aryeh Gregor) > 8. Re: Subpage titles (Michael J. Walsh) > 9. Re: Subpage titles (Aryeh Gregor) > 10. Re: Subpage titles (Ilmari Karonen) > 11. Re: Subpage titles (Daniel Friesen) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 29 Dec 2008 23:45:55 -0700 >From: "Remember the dot" <rememberthedot(a)gmail.com> >Subject: Re: [Wikitech-l] Subpage titles >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <17aa57b60812292245i40d888a8xcde6bfe6d8b7cc3f(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >On Mon, Dec 29, 2008 at 8:31 PM, Soxred93 <soxred93(a)gmail.com> wrote: > >> Hopefully, if the new DISPLAYTITLE functionality goes into effect, >> the effect of this can be done. > > >What new DISPLAYTITLE functionality? Is this separate from >https://bugzilla.wikimedia.org/show_bug.cgi?id=12998 ? > >-- >Remember the dot >http://en.wikipedia.org/wiki/User:Remember_the_dot > > >------------------------------ > >Message: 2 >Date: Tue, 30 Dec 2008 17:23:09 +0100 >From: Platonides <Platonides(a)gmail.com> >Subject: Re: [Wikitech-l] Anchors haven't id attribute >To: wikitech-l(a)lists.wikimedia.org >Message-ID: <gjdhtd$pg5$1(a)ger.gmane.org> >Content-Type: text/plain; charset=ISO-8859-1 > >Aryeh Gregor wrote: >>> the idea of "broken code must render anyway" >>> is riped. It must die, a painfull dead, because is the father and >>> mother of the tag soup, that is more vile than the Borg and Microsoft >>> *combined* >> >> Browser vendors are not willing to remove support for it, because it >> would break old websites. HTML5 says broken code is invalid, but aims >> to standardize in great detail how browsers should render it anyway, >> instead of demanding (impractically) that they throw up their arms and >> die like XHTML insists on. A "feature" of XHTML that practically >> everyone skips in practice by serving it as text/html. > >Even if you want to use it, "some browsers" don't support it so you end >with ugly user-agent sniffing hacks. > > > > >------------------------------ > >Message: 3 >Date: Tue, 30 Dec 2008 09:17:17 -0600 >From: "Charlotte Webb" <charlottethewebb(a)gmail.com> >Subject: Re: [Wikitech-l] Separating section anchors from other IDs > (was: Anchors haven't id attribute) >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <4286fc440812300717o323c35cao7871a13204ddd9b0(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On 12/28/08, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: >> Now, how about figuring out how to get manually-specified id's like >> <span id="foo"> to be unique? :) > >Could just number them sequentially like we do the section headings. > >...or try to convince the creators of id="stub" templates that there's >something wrong with giving them all the same id (good luck with that, >they wouldn't listen to me). > >?C.W. > >------------------------------ > >Message: 4 >Date: Tue, 30 Dec 2008 09:30:24 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] Subpage titles >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812300630n6eaefb74s7f1f73992eda692c(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Mon, Dec 29, 2008 at 9:59 PM, K. Peachey <p858snake(a)yahoo.com.au> wrote: >> Maybe have a little button in the right/opposite corner that you click >> and uses js magic to copy it to the clipboard maybe? > >That's just not intuitive. People are going to try copying it and it >won't work. > >On Mon, Dec 29, 2008 at 11:16 PM, Daniel Friesen <dan_the_man(a)telus.net> wrote: >> Traditionally in cases where the title does not actually depict the >> title itself properly I believe the idea has been to add some sort of >> "Full title: ..." to the subtitle. > >This is ugly and confusing, and people still are going to try copying >it directly and it won't work. > >I think that 301ing pages with " ? " in their title to pages with "/" >is the best way here, for Wikisource and other projects that want >prettier subpage display for deeply nested subpages (probably not for >Wikipedia, although you can make an argument for consistency). > >------------------------------ > >Message: 5 >Date: Tue, 30 Dec 2008 22:33:10 +0100 >From: Platonides <Platonides(a)gmail.com> >Subject: Re: [Wikitech-l] Subpage titles >To: wikitech-l(a)lists.wikimedia.org >Message-ID: <gje42m$hct$1(a)ger.gmane.org> >Content-Type: text/plain; charset=UTF-8 > >Aryeh Gregor wrote: >> On Mon, Dec 29, 2008 at 9:59 PM, K. Peachey <p858snake(a)yahoo.com.au> wrote: >>> Maybe have a little button in the right/opposite corner that you click >>> and uses js magic to copy it to the clipboard maybe? >> >> That's just not intuitive. People are going to try copying it and it >> won't work. >> >> On Mon, Dec 29, 2008 at 11:16 PM, Daniel Friesen <dan_the_man(a)telus.net> wrote: >>> Traditionally in cases where the title does not actually depict the >>> title itself properly I believe the idea has been to add some sort of >>> "Full title: ..." to the subtitle. >> >> This is ugly and confusing, and people still are going to try copying >> it directly and it won't work. >> >> I think that 301ing pages with " ? " in their title to pages with "/" >> is the best way here, for Wikisource and other projects that want >> prettier subpage display for deeply nested subpages (probably not for >> Wikipedia, although you can make an argument for consistency). > >What about providing " ? " as a image with alt="/" ? > > > > >------------------------------ > >Message: 6 >Date: Tue, 30 Dec 2008 17:09:52 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] Separating section anchors from other IDs > (was: Anchors haven't id attribute) >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812301409m2c757fd9ta2ba62e6a02833d4(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Tue, Dec 30, 2008 at 10:17 AM, Charlotte Webb ><charlottethewebb(a)gmail.com> wrote: >> Could just number them sequentially like we do the section headings. > >Alternatively, we could strip them and add an HTML comment -- we need >to have some id for the extra section headings, because we need to >link to them automatically, but that seems to be of dubious benefit >for user-supplied id's. If they're using them for anything, their use >(e.g., CSS rule, getElementById()) will almost certainly fail if we >modify the id in any way, so no point in keeping it at all. > >> ...or try to convince the creators of id="stub" templates that there's >> something wrong with giving them all the same id (good luck with that, >> they wouldn't listen to me). > >Well, if we wanted to, telling them "in one week it will stop working" >should do it. Or just having a sysop there do it unilaterally with >that as edit summary. I don't know if we want to, though. It would >be disruptive for questionable benefit. As I said, if we do this we'd >have to do a dry run for a while and only log conflicts, and deal with >all the major problem-causers before enabling it for real. > > > >------------------------------ > >Message: 7 >Date: Tue, 30 Dec 2008 17:13:40 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] Subpage titles >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812301413p71a44d1t5781e568e4736b38(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Tue, Dec 30, 2008 at 4:33 PM, Platonides <Platonides(a)gmail.com> wrote: >> What about providing " ? " as a image with alt="/" ? > >1) That's just horribly ugly when the other solution would be simple enough. > >2) Can we rely on the fact that images are copy-pasted as their alt >text in all browsers? > >------------------------------ > >Message: 8 >Date: Wed, 31 Dec 2008 01:01:19 +0000 >From: "Michael J. Walsh" <michaelj.walsh(a)oceanfree.net> >Subject: Re: [Wikitech-l] Subpage titles >To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> >Message-ID: <868228FD-778C-487F-B86F-CD7C8D741BAC(a)oceanfree.net> >Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed > > >On 30 Dec 2008, at 22:13, Aryeh Gregor wrote: > >> On Tue, Dec 30, 2008 at 4:33 PM, Platonides <Platonides(a)gmail.com> >> wrote: >>> What about providing " ? " as a image with alt="/" ? >> >> 1) That's just horribly ugly when the other solution would be >> simple enough. >> >> 2) Can we rely on the fact that images are copy-pasted as their alt >> text in all browsers > >What about programming the software to replace " ? " in links with >"/" before submitting to the database or previewing the page. > > >------------------------------ > >Message: 9 >Date: Tue, 30 Dec 2008 20:46:33 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] Subpage titles >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812301746hcc595fcwe2c9cc587539342c(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Tue, Dec 30, 2008 at 8:01 PM, Michael J. Walsh ><michaelj.walsh(a)oceanfree.net> wrote: >> What about programming the software to replace " ? " in links with >> "/" before submitting to the database or previewing the page. > >More pre-save transforms? We should probably be reducing the number, >not increasing them. This one has more merit than pipe tricks, >though. It's a possibility. It would probably be simpler to do the >301, though. > >------------------------------ > >Message: 10 >Date: Wed, 31 Dec 2008 05:03:18 +0200 >From: Ilmari Karonen <nospam(a)vyznev.net> >Subject: Re: [Wikitech-l] Subpage titles >To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> >Message-ID: <495AE0F6.6010906(a)vyznev.net> >Content-Type: text/plain; charset=ISO-8859-15; format=flowed > >Aryeh Gregor wrote: >> On Tue, Dec 30, 2008 at 8:01 PM, Michael J. Walsh >> <michaelj.walsh(a)oceanfree.net> wrote: >>> What about programming the software to replace " ? " in links with >>> "/" before submitting to the database or previewing the page. >> >> More pre-save transforms? We should probably be reducing the number, >> not increasing them. This one has more merit than pipe tricks, >> though. It's a possibility. It would probably be simpler to do the >> 301, though. > >If not a PST, it would pretty much have to be done in title >normalization. For one thing, we'd need it for link existence checks. > >But I have a simpler suggestion: why not display the title just like we >do now, but use CSS to add some padding around the slashes and to render >everything up to the last slash in smaller font on a separate line? >Should be easy enough to do with just a couple of simple <span> tags, >and be perfectly cut-and-pasteable. Granted, it means sticking with "/" >as the delimiter instead of "?", but I wouldn't think that'd be a >blocking issue. > >-- >Ilmari Karonen > > > >------------------------------ > >Message: 11 >Date: Tue, 30 Dec 2008 21:32:28 -0800 >From: Daniel Friesen <dan_the_man(a)telus.net> >Subject: Re: [Wikitech-l] Subpage titles >To: wikitech-l(a)lists.wikimedia.org >Message-ID: <gjf05f$iqm$1(a)ger.gmane.org> >Content-Type: text/plain; charset=ISO-8859-15; format=flowed > >Back on the image note..... Why alt? it doesn't have to be alt, a >background image should be suitable. >Break up a title by / wrap each section in a span and place proper >padding on them -- ;) if you want to do something real nice, turn >everything but the last portion into a link -- and replace every / by a >span containing / with display: none; and followed by an empty span with >a background image. > >~Daniel Friesen (Dantman, Nadir-Seen-Fire) >~Profile/Portfolio: http://nadir-seen-fire.com >-The Nadir-Point Group (http://nadir-point.com) >--It's Wiki-Tools subgroup (http://wiki-tools.com) >--The ElectronicMe project (http://electronic-me.org) >-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) >--Animepedia (http://anime.wikia.com) >--Narutopedia (http://naruto.wikia.com) > > > >Ilmari Karonen wrote: >> Aryeh Gregor wrote: >> >>> On Tue, Dec 30, 2008 at 8:01 PM, Michael J. Walsh >>> <michaelj.walsh(a)oceanfree.net> wrote: >>> >>>> What about programming the software to replace " ? " in links with >>>> "/" before submitting to the database or previewing the page. >>>> >>> More pre-save transforms? We should probably be reducing the number, >>> not increasing them. This one has more merit than pipe tricks, >>> though. It's a possibility. It would probably be simpler to do the >>> 301, though. >>> >> >> If not a PST, it would pretty much have to be done in title >> normalization. For one thing, we'd need it for link existence checks. >> >> But I have a simpler suggestion: why not display the title just like we >> do now, but use CSS to add some padding around the slashes and to render >> everything up to the last slash in smaller font on a separate line? >> Should be easy enough to do with just a couple of simple <span> tags, >> and be perfectly cut-and-pasteable. Granted, it means sticking with "/" >> as the delimiter instead of "?", but I wouldn't think that'd be a >> blocking issue. >> >> > > > > >------------------------------ > >_______________________________________________ >Wikitech-l mailing list >Wikitech-l(a)lists.wikimedia.org >https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > >End of Wikitech-l Digest, Vol 65, Issue 40 >****************************************** >

1 0

Anchors haven't id attribute
by Sylvain Brunerie 30 Dec '08

30 Dec '08

Isn't it recommanded to use id rather than name to create anchors? If so, it could be a good idea to fix this. We could add the id attribute with the same value as the name attribute. In Linker.php, line 1521 ( http://svn.wikimedia.org/doc/Linker_8php-source.html#l01521) : > public function makeHeadline( $level, $attribs, $anchor, $text, $link ) { > return "<a name=\"$anchor\"></a><h$level$attribs$link <span > class=\"mw-headline\">$text</span></h$level>"; > } > (Tell me if I'm wrong.) — Sylvain Brunerie [[w:fr:User:Delhovlyn]]

12 47

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 29 Dec '08

29 Dec '08

MediaWiki Bugzilla Report for December 22, 2008 - December 29, 2009 Status changes this week Bugs NEW : 132 Bugs ASSIGNED : 5 Bugs REOPENED : 14 Bugs RESOLVED : 70 Total bugs still open: 3213 Resolutions for the week: Bugs marked FIXED : 40 Bugs marked REMIND : 0 Bugs marked INVALID : 6 Bugs marked DUPLICATE : 10 Bugs marked WONTFIX : 5 Bugs marked WORKSFORME : 6 Bugs marked LATER : 4 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component General/Unknown 10 General/Unknown 5 Images 3 Categories 3 Uploading 3 New Bugs Per Product MediaWiki 33 Wikimedia 13 MediaWiki extensions 11 Top 5 Bug Resolvers brion [AT] wikimedia.org 15 JSchulz_4587 [AT] msn.com 13 raimond.spekking [AT] gmail.com 9 davemccabe [AT] gmail.com 4 mrzmanwiki [AT] gmail.com 4

2 1

IBM DB2 patch for MediaW iki
by Leons Petrazickis 29 Dec '08

29 Dec '08

Hello, I work on the DB2 database server at IBM. In my personal time, I've written a patch to add DB2 support to MediaWiki. It supports most of the MediaWiki Database API with some gaps in searching and admin. I'm involved in launching a site based on the patch and moving another wiki onto it, so the gaps should be plugged in due time. I don't have commit access. Could someone help get this committed? The patch is against r43499 of the trunk: <http://lpetr.org/ibm_db2_patch/> The diff defines the changes to existing files: <http://lpetr.org/ibm_db2_patch/add_ibm_db2.diff> Changes: - Improved database agnosticism in Special pages (good for DB2, MSSQL, Oracle) - DB2 interface options in the config index.php - Some new constants like TS_DB2 for DB2 timestamp format There are also three new files: <http://lpetr.org/ibm_db2_patch/includes/db/DatabaseIbm_db2.php> <http://lpetr.org/ibm_db2_patch/includes/SearchIBM_DB2.php> <http://lpetr.org/ibm_db2_patch/maintenance/ibm_db2/tables.sql> They are named to match the existing database files. Capitalization is a bit inconsistent for compatibility. 'ibm_db2' is the name of the required PHP extension, and the config/index.php algorithm requires Ibm_db2 spelling for the Database module. Etc. IBM DB2 is available for free download at <http://tinyurl.com/6lg5pa> My public SSH key is <http://lpetr.org/personal/leo-public.pub> Regards, Leons Petrazickis http://lpetr.org/blog/

12 23

Re: [Wikitech-l] Wikitech-l Digest, Vol 65, Issue 34
by Ján Uličný 28 Dec '08

28 Dec '08

SOS...SOS...SOS...HELP...Slovakia-Slovensko,dakujem za E-mail ale neviem čo tam je napísané,lebo neovládam Váš jazyk -prosím Slovenčinu alebo češtinu... ______________________________________________________________ > Od: wikitech-l-request(a)lists.wikimedia.org > Komu: wikitech-l(a)lists.wikimedia.org > Datum: 28.12.2008 04:16 > Předmět: Wikitech-l Digest, Vol 65, Issue 34 > >Send Wikitech-l mailing list submissions to > wikitech-l(a)lists.wikimedia.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >or, via email, send a message with subject or body 'help' to > wikitech-l-request(a)lists.wikimedia.org > >You can reach the person managing the list at > wikitech-l-owner(a)lists.wikimedia.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Wikitech-l digest..." > > >Today's Topics: > > 1. Data center move in Amsterdam: expect some downtime (Mark Bergsma) > 2. Re: IBM DB2 patch for MediaWiki (Jes?s Quiroga) > 3. Re: Anchors haven't id attribute (Danny B.) > 4. Re: Anchors haven't id attribute (Brion Vibber) > 5. Re: IBM DB2 patch for MediaWiki (Aryeh Gregor) > 6. Re: Anchors haven't id attribute (Aryeh Gregor) > 7. Re: Anchors haven't id attribute (Danny B.) > 8. Re: Anchors haven't id attribute (Aryeh Gregor) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 26 Dec 2008 22:05:17 +0100 >From: Mark Bergsma <mark(a)wikimedia.org> >Subject: [Wikitech-l] Data center move in Amsterdam: expect some > downtime >To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Wikimedia > Foundation Mailing List <foundation-l(a)lists.wikimedia.org> >Message-ID: <4955470D.10503(a)wikimedia.org> >Content-Type: text/plain; charset=ISO-8859-1 > >In the upcoming days until new years we will be moving our servers and >other equipment in the Amsterdam data center location to a new data >center. Unfortunately this might result in some down time and hiccups of >certain web sites & services, although we will try to keep this to a >minimum. > >On Sunday the 28th, between 09:00 and 11:00 UTC we will migrate our >network in Amsterdam to new equipment. All services located there will >be unreachable for a brief period. Traffic for the main wikis will be >rerouted to the Florida cluster however, and should remain unaffected. > >In the days after we will be moving the servers themselves. Some >services, such as the mailing lists server, the subversion server and >the toolserver cluster, will be down for a number of hours while the >equipment is being moved. Traffic for the wikis should again remain >largely unaffected. > >We hope to have the entire migration finished before we enter the last >few hours of 2008... and start 2009 with a clean sheet. Happy Holidays >everyone! > >-- >Mark Bergsma <mark(a)wikimedia.org> >System & Network Administrator, Wikimedia Foundation > > > >------------------------------ > >Message: 2 >Date: Sat, 27 Dec 2008 07:23:00 +0100 >From: Jes?s Quiroga <jquiroga(a)pobox.com> >Subject: Re: [Wikitech-l] IBM DB2 patch for MediaWiki >To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> >Message-ID: <4955C9C4.9080509(a)pobox.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >Hello. > >After a few days of pondering the issues, I would like to explain what I >suggested in my previous message, in more detail and (hopefully) more >clearly. > >What I'm about to say is pretty abstract, so it's difficult to convey >the right meaning. Please forgive me if I say something you already >know, or just nonsense :-) > > >Jes?s Quiroga escribi?: >> I believe a better solution is to design a domain-specific language, an >> idea not very different from your first one. >> This DSL would model the interaction between the application and the DB >> as it is now, and would be designed to evolve. That's it. >> > >The problem I discuss is how to best access the data store from an >application. I believe the right answer is different for each project, >but it's not difficult to evaluate the alternatives, one by one, in a >given context. I think it is worthwhile to do that in the context of >MediaWiki. > >I will refer to wiki modules and databases as if they were 'hosts' >connected to a 'network', to highlight the role of languages in the >operation of the system at runtime. > > >The first way to access the data store is the 'direct' one: > > [polyglot wiki] <--- mysDataL ---> [mysql] > [polyglot wiki] <--- posDataL ---> [postgresql] > [polyglot wiki] <--- db2DataL ---> [db2] > >Here, the polyglot wiki module talks to every database using the proper >languages. 'mysDataL' means 'the data language understood by MySQL', >'posDataL' means 'the data language understood by PostgreSQL', etc. > >The polyglot wiki promises to learn several languages and to speak them >correctly forever, so, if a new database comes along or any of their >data languages evolves, the polyglot wiki is forced to adapt at a >potentially great cost. Besides, any change to the database schema can >trigger lots of updates to the wiki code, and be very costly too. > >The advantages of this way are well known: it is fast, no need to do >design, easy to understand. >The drawbacks are apparently few, but devastating: verbose and complex >code in multiple places in the wiki module, very costly to maintain, >even more costly to evolve. All changes cost a lot, in time and effort. > > > >The second way to access the data store that is usually considered is >the 'indirect' one: > > [wiki] <--- wikiDataL ---> [polyglot translator] > > [polyglot translator] <--- mysDataL ---> [mysql] > [polyglot translator] <--- posDataL ---> [postgresql] > [polyglot translator] <--- db2DataL ---> [db2] > >Here, wikiDataL means 'some relational data definition and manipulation >language suitable for use by the wiki'. > >The polyglot translator promises to learn wikiDataL and the other >dialects and to evolve with them, so it has all the problems the wiki >had in the direct way, but now the cost is lower because a lot of >complexity is 'hidden' inside the translator and can't reach the wiki. >As a result, wiki code is not updated as much, and it's much cleaner and >less verbose. > >The advantages of this way are: wiki module code is simpler, cost of >evolution is reduced. >The drawbacks are apparently many: it's slower, design is needed, harder >to understand, a new language (wikiDataL), translator can be very >complex. However, the need to reduce the cost to achieve change is >usually so great that these inconveniences are minor in comparison. > > > >Now the interesting bit begins. A third possible way to access the data >store, the 'interpreted' one: > > [wiki] <--- wikiNeedL ---> [polyglot interpreter] > > [polyglot interpreter] <--- mysDataL ---> [mysql] > [polyglot interpreter] <--- posDataL ---> [postgresql] > [polyglot interpreter] <--- db2DataL ---> [db2] > >Here, wikiNeedL means 'some language adequate for the wiki to express >its data access needs and nothing else'. > >wikiNeedL is the domain-specific language I wrote about in my previous >message. > >The differences between wikiDataL and wikiNeedL are mainly these: > - wikiNeedL would contain just enough wiki concepts to express the >wiki's needs, so it's effectively confined to that domain. wikiDataL >belongs to the relational data model domain, which is quite different. > - in general, wikiNeedL would have different semantics than the >dialects understood by the databases, so the translation step becomes >more like interpretation, rather than just syntactic transformations. >wikiDataL usually has the same semantics than the dialects. > - wikiNeedL would contain just enough concepts to satisfy current >needs, and will be open to extension. wikiDataL aims to be >general-purpose and to fulfill current and future needs. > >The main reason to consider the 'interpreted' way is, of course, that it >helps reduce even more the cost to achieve change. > > > >So that's what I was talking about. I will say more about the >differences between the indirect and the interpreted ways in a future >message. > > > >Thanks for your attention. > > > > > >------------------------------ > >Message: 3 >Date: Sat, 27 Dec 2008 13:05:53 +0100 (CET) >From: Danny B.<Wikipedia.Danny.B(a)email.cz> >Subject: Re: [Wikitech-l] Anchors haven't id attribute >To: Wikimedia developers<wikitech-l(a)lists.wikimedia.org> >Message-ID: <18263.21683-30277-135341947-1230379553(a)email.cz> >Content-Type: text/plain; charset="iso-8859-2" > >> ------------ P?vodn? zpr?va ------------ >> Od: Brion Vibber <brion(a)wikimedia.org> >> P?edm?t: Re: [Wikitech-l] Anchors haven't id attribute >> Datum: 26.12.2008 06:30:00 >> ---------------------------------------- >> On 12/25/08 4:32 AM, Danny B. wrote: >> > I have reverted both revisions in r45021 and r45022 because it caused massive >> invalidity of pages. >> >> Given that we've been outputting these as "id" attributes for the last >> few years already (as output by Tidy), I have reverted your revert in >> r45044 pending further discussion. >> >> -- brion > >Well, the id was added _only_ to those tags, where name was transferable to id - thus had to start with ASCII letter. _Never_ to those, which did not conform this rule (the regexp mentioned in my previous post). Easily provable by either running older revision of MediaWiki or testing in Tidy directly: > >Take this code excerpt (and wrap it with minimal XHTML document stuff) and run it through Tidy: > ><a name="X"></a><h2> <span class="mw-headline"> X </span></h2> ><a name="1X"></a><h2> <span class="mw-headline"> 1X </span></h2> ><a name=".C3.81X"></a><h2> <span class="mw-headline"> ?X </span></h2> ><a name="-X"></a><h2> <span class="mw-headline"> -X </span></h2> > >The result will be: > ><a name="X" id="X"></a><h2><span class="mw-headline">X</span></h2> ><a name="1X"></a><h2><span class="mw-headline">1X</span></h2> ><a name=".C3.81X"></a><h2><span class="mw-headline">?X</span></h2> ><a name="-X"></a><h2><span class="mw-headline">-X</span></h2> > >Now, let me repeat, how the "id" is defined: > >1: XHTML is reformulation of HTML 4 as an XML 1.0 application. >2: That means it takes every single definition from HTML 4 and keeps it unless it is overriden in XHTML. >3: The id and name has been defined in HTML 4 as /[A-Za-z][A-Za-z0-9:_.-]*/ [1] [2] >4: The name has been redefined to NMTOKEN [2] [3] >5: The id has never been redefined thus stays on definition mentioned in point 3 above. > >This is how the id in XHTML was always handled since the XHTML is out. I also think that such important thing like handling of id is, was fixed in validator during so many years if it wasn't correct. > >So currently, all non-latin-chars wikis are now totally invalid according to W3C validator. Major parts of non-ASCII-chars wikis are invalid as well. Therefore is very hard to find other invalid mistakes in code when having worthless positives on every other page. :-( > >Also one thing at the end: I think that the current rendering with controversial ids brought more negatives (such as much lowering down the ability to find the real invalid parts of the code) than positives - well, it was working correctly before, so what benefit it actually brought? On the other hand it brought this controversy. > >I take the point that I (and majority of people over the world, the validator, Tidy and so many other tools etc.) _may_ be wrong with the interpretation of definition of id. But I guess unless the authority tools, as validator or Tidy are, are fixed in this issue - thus can be proved we render the page correctly - we should not render that way. As I mentioned above - it was working correctly before so there is no urge to force the new rendering since it is not correcting any mistake or misfunctionality. > >[1] http://www.w3.org/TR/html401/types.html#type-name >[2] http://www.w3.org/TR/xhtml1/#C_8 >[3] http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken > > >Kind regards > > >Danny B. > > > >------------------------------ > >Message: 4 >Date: Sat, 27 Dec 2008 12:14:33 -0800 >From: Brion Vibber <brion(a)wikimedia.org> >Subject: Re: [Wikitech-l] Anchors haven't id attribute >To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> >Message-ID: <49568CA9.6090104(a)wikimedia.org> >Content-Type: text/plain; charset=ISO-8859-2; format=flowed > >[snip] > >Maybe we should just fix the normalization function the way we'd already >planned to, so that it'll work right the way we'd already planned to? > >-- brion > > > >------------------------------ > >Message: 5 >Date: Sat, 27 Dec 2008 18:25:10 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] IBM DB2 patch for MediaWiki >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812271525g3055d1ffr855bc071028262b(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Sat, Dec 27, 2008 at 1:23 AM, Jes?s Quiroga <jquiroga(a)pobox.com> wrote: >> The second way to access the data store that is usually considered is >> the 'indirect' one: >> >> [wiki] <--- wikiDataL ---> [polyglot translator] >> >> [polyglot translator] <--- mysDataL ---> [mysql] >> [polyglot translator] <--- posDataL ---> [postgresql] >> [polyglot translator] <--- db2DataL ---> [db2] >> >> Here, wikiDataL means 'some relational data definition and manipulation >> language suitable for use by the wiki'. > >This is what we currently use, and I don't think we're going to >seriously consider changing it without some very compelling arguments >being presented. Incremental improvements to our current way of doing >things (cutting back on raw queries, moving MySQL-specific stuff from >Database to DatabaseMySql, defining more clearly what Database methods >mean and avoiding undefined behavior) seem entirely sufficient to >allow support for any number of additional database backends. > >> The differences between wikiDataL and wikiNeedL are mainly these: >> - wikiNeedL would contain just enough wiki concepts to express the >> wiki's needs, so it's effectively confined to that domain. wikiDataL >> belongs to the relational data model domain, which is quite different. >> - in general, wikiNeedL would have different semantics than the >> dialects understood by the databases, so the translation step becomes >> more like interpretation, rather than just syntactic transformations. >> wikiDataL usually has the same semantics than the dialects. >> - wikiNeedL would contain just enough concepts to satisfy current >> needs, and will be open to extension. wikiDataL aims to be >> general-purpose and to fulfill current and future needs. > >In practice, wikiNeedL would be drastically more complicated, if I >understand you correctly. Its basic semantic units would be things >like articles, users, revisions, etc., instead of rows, columns, and >tables. We *have* a wikiNeedL, in fact: it's called "calling the >appropriate Article method" or whatever. Most code doesn't have to >manually do queries. Further abstraction of the database queries >would be possible, but I question its usefulness. > >------------------------------ > >Message: 6 >Date: Sat, 27 Dec 2008 19:06:24 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] Anchors haven't id attribute >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812271606u6b188edj22a6579803ccd43d(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Sat, Dec 27, 2008 at 3:14 PM, Brion Vibber <brion(a)wikimedia.org> wrote: >> [snip] >> >> Maybe we should just fix the normalization function the way we'd already >> planned to, so that it'll work right the way we'd already planned to? > >Done in r45109. I notice, by the way, that HTML5 allows any string >not containing whitespace for id's . . . yet another case where it >clearly wins the "don't gratuitously cause pain to developers" >contest. > > > >------------------------------ > >Message: 7 >Date: Sun, 28 Dec 2008 03:02:26 +0100 (CET) >From: Danny B.<Wikipedia.Danny.B(a)email.cz> >Subject: Re: [Wikitech-l] Anchors haven't id attribute >To: Wikimedia developers<wikitech-l(a)lists.wikimedia.org> >Message-ID: <18278.21698-2886-1817746719-1230429746(a)email.cz> >Content-Type: text/plain; charset="iso-8859-2" > >> ------------ P?vodn? zpr?va ------------ >> Od: Aryeh Gregor <Simetrical+wikilist(a)gmail.com> >> P?edm?t: Re: [Wikitech-l] Anchors haven't id attribute >> Datum: 28.12.2008 01:07:08 >> ---------------------------------------- >> On Sat, Dec 27, 2008 at 3:14 PM, Brion Vibber <brion(a)wikimedia.org> wrote: >> > [snip] >> > >> > Maybe we should just fix the normalization function the way we'd already >> > planned to, so that it'll work right the way we'd already planned to? >> >> Done in r45109. I notice, by the way, that HTML5 allows any string >> not containing whitespace for id's . . . yet another case where it >> clearly wins the "don't gratuitously cause pain to developers" >> contest. > >*sigh* > >Why do we have to hunt for some other solution when we have fully working, fully valid and fully intuitive one? > >OK, let's make some summary about three versions we have: > >Terms used: >- old version - the for-many-years used version until r44896 >- mid version - r44896 way >- new version - r45109 way > >Old version was used for many years. It was fully valid - ids were only there where they could have been copied from name AND comply to the regexp mentioned in previous posts. It has been done automatically by Tidy. And it was fully intuitive - you just wrote [[#Foo]] and it linked to section named Foo. Or you've added #Foo in URL in address bar and you got to the proper section as well. And it was fully working properly. > >The mid version brought the "feature" that all name attributes have been duplicated to ids. That caused massive invalidity of pages, especially non-latin and non-ASCII. However, the intuitivity of anchors creation has still been kept. > >The new version prepends x to all anchors to solve the problem which was spread here in mid version - the massive invalidity of pages. So it solved one problem (which actually didn't have to be solved if we kept the old version) but brought at least two major other: >First major problem is, that this change is breaking millions of existing links to sections. Links used on pages on wikis, links used on external sites, links in people's bookmarks, in emails, forum threads etc. Well, OK, let's discount all external stuff, since we don't have any influence on it, but we still have millions of links left on our own wikis which won't work anymore since r45109. >The other major problem is, that since this point further the anchor links are no longer intuitive - we are now pushing people to constantly think about prepending x when creating anchor links. No more simple copy pasting of the headline. >As a side effect we are now adding unnecessary work to people from non-latin wikis by pushing them to always switch to latin keyboard, or to click on edittools or whatever just to get the one "x" character in editbox to create the anchor link. > >So let me summarize in points: >* First we did not have any problem at all. >* Second we had one problem. >* Third we "solved" the problem but created at least two new. >I am pretty scared what's coming next... :-/ > >One question for the end: What is the benefit of either mid or new version over the old one - what new functionality or feature it brings or which existing bug it fixes? > > >Kind regards > > >Danny B. > > > >------------------------------ > >Message: 8 >Date: Sat, 27 Dec 2008 22:15:24 -0500 >From: "Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> >Subject: Re: [Wikitech-l] Anchors haven't id attribute >To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> >Message-ID: > <7c2a12e20812271915gf2bb722gd33f461fb180b946(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >2008/12/27 Danny B. <Wikipedia.Danny.B(a)email.cz>: >> *sigh* >> >> Why do we have to hunt for some other solution when we have fully working, fully valid and fully intuitive one? > >Because: > >1) Our previous behavior arguably violated the XHTML 1 specification >by allowing name attributes to begin with nonletters. Please don't >ignore this argument because you think it's wrong. I think you're >wrong on this issue too, but I don't just ignore your opinion when >discussing what the software that we *both* develop should do. Note >"arguably" in the first sentence here -- your opinion counts as much >as mine. > >2) It's not arguable at all that the XHTML 1 specification strongly >recommends that <a> elements with a name attribute also have an id >attribute. In fact, section 4.10 states: "In order to ensure that >XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 >documents MUST use the id attribute when defining fragment identifiers >on the elements listed above [including <a>]." > >I'm not saying these reasons outweigh the reasons against, but those >are the reasons it was done. In particular, I don't think I've seen >an argument from you against (2). > >> Old version was used for many years. It was fully valid > >Could you *please* stop pretending that a debate doesn't even exist >here? It's obnoxious and uncivil, and you keep on doing it. > >> First major problem is, that this change is breaking millions of existing links to sections. Links used on pages on wikis, links used on external sites, links in people's bookmarks, in emails, forum threads etc. Well, OK, let's discount all external stuff, since we don't have any influence on it, but we still have millions of links left on our own wikis which won't work anymore since r45109. > >First of all, all auto-generated internal links (in TOCs) will >automatically switch to the new format. Second of all, it should be >one extra line of code to fix up all manually-created internal links >as well, so that the x is automatically added as part of the encoding >process. (I didn't find where this needed to be done at a quick >glance.) So we're only talking about external links here. > >This is a one-time cost and I don't think it's a big problem -- at >worst, a few users will end up on the wrong part of the page. It >should be pointed out that this will affect *all* section links on >non-Latin wikis (since they get encoded to begin with dots and then >need to start with a letter), but again, only as a one-time cost, and >only external links (links from external sites or links using external >link syntax), and it will still get viewers to almost the right place. > >> The other major problem is, that since this point further the anchor links are no longer intuitive - we are now pushing people to constantly think about prepending x when creating anchor links. No more simple copy pasting of the headline. >> As a side effect we are now adding unnecessary work to people from non-latin wikis by pushing them to always switch to latin keyboard, or to click on edittools or whatever just to get the one "x" character in editbox to create the anchor link. > >Again, not an issue if internal links are fixed to work correctly. I >didn't think about that aspect, but it should be very simple to fix >(I'd do it now except I'm going to bed). > >It seems to me that there are only weak reasons in favor (following >recommended best practice with no practical effect) and only weak >reasons against (small one-time transition cost -- unless you're >correct that there will be longer-term costs, in which case please >clarify why you think this). Normally I would say that standards >compliance by itself (as opposed to standards compliance that brings >concrete benefit) is worth small one-time costs, although not large >enough one-time costs and probably not even fairly small recurring >costs. So as it stands, without further arguments, I'd still be >weakly in favor of keeping the current state of trunk, of course with >the fix for anchors on internal links. > > > >------------------------------ > >_______________________________________________ >Wikitech-l mailing list >Wikitech-l(a)lists.wikimedia.org >https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > >End of Wikitech-l Digest, Vol 65, Issue 34 >****************************************** >

1 0

Data center move in Amsterdam: expect some downtime
by Mark Bergsma 26 Dec '08

26 Dec '08

In the upcoming days until new years we will be moving our servers and other equipment in the Amsterdam data center location to a new data center. Unfortunately this might result in some down time and hiccups of certain web sites & services, although we will try to keep this to a minimum. On Sunday the 28th, between 09:00 and 11:00 UTC we will migrate our network in Amsterdam to new equipment. All services located there will be unreachable for a brief period. Traffic for the main wikis will be rerouted to the Florida cluster however, and should remain unaffected. In the days after we will be moving the servers themselves. Some services, such as the mailing lists server, the subversion server and the toolserver cluster, will be down for a number of hours while the equipment is being moved. Traffic for the wikis should again remain largely unaffected. We hope to have the entire migration finished before we enter the last few hours of 2008... and start 2009 with a clean sheet. Happy Holidays everyone! -- Mark Bergsma <mark(a)wikimedia.org> System & Network Administrator, Wikimedia Foundation

1 0

Extension:Pdfhandler
by Luiz Augusto 26 Dec '08

26 Dec '08

What is the current status of Extension:Pdfhandler and bugzilla:11215? It needs more testing or it will never get enabled due to Adobe patents? How can geeks and non-geeks wikimedians can help on debugging that extension? I'm asking it because I've approximately 30GB of public domain scans in .pdf format to upload on Commons on the next months (see http://en.wikisource.org/w/index.php?oldid=928004#Royal_Society_Digital_Arc… further information on it) and because I fully agree to the reasons listed on https://bugzilla.wikimedia.org/show_bug.cgi?id=11215#c3 [Yeah, I'm asking it in the Christmas day... Extension:Pdfhandler and Extension:ABC are good options of christmas gifts for Wikisource wikis ;-) ]

4 5

Using tab inside articles
by Mohsen A. Momeni 25 Dec '08

25 Dec '08

Hi, I want to use tabs inside my articles in my wiki. I don't want the page loads again anytime a tab is clicked. Is there any simple method to do this? Regards, -- __ \ /_\\_-//_ Mohsen A. Momeni

2 1

Wikimedia sites updated to r44990
by Brion Vibber 24 Dec '08

24 Dec '08

It's weekly code review update time! :) Some changes of note... User preferences: * (bug 505) Time zones can now be specified by location in user preferences, avoiding the need to manually update for DST. Patch by Brad Jorsch. Web standards behavior: * (bug 2585) HTTP 404 return code is now given for a page view if the page does not exist, allowing spiders and link checkers to detect broken links. * (bug 16459) Use native getElementsByClassName where possible, for better performance in modern browsers Localization/UI changes: * (bug 16612) Fixed "noprint" class for Modern skin print style * (bug 16712) Special:NewFiles updated to use "newer"/"older" paging messages for clarity over "previous/next" * (bug 16026) revision-info, revision-info-current, cannotdelete, redirectedfrom, historywarning and difference messages now use Wiki text rather than raw HTML markup Upload/file-handling issues: * (bug 13835) Fix rendering of {{filepath:Wiki.png|nowiki}} * (bug 16772) Special:Upload now correctly rejects files with spaces in the file extension (e.g. Foo. jpg). API changes: * (bug 16726) siprop=namespacealiases should also list localized aliases * (bug 16730) Added apprfiltercascade parameter to list=allpages to filter cascade-protected pages -- brion

2 1

404 status codes for broken links
by Brion Vibber 23 Dec '08

23 Dec '08

In r44919 I've gone ahead and reimplemented bug 2585, so a page view for a nonexistent page will return a "404 Not Found" HTTP status code instead of a "200 OK". This will allow bots and spiders to detect broken links from the outside web to bad or deleted wiki pages, but should be totally transparent to end-users. When we first attempted this in 2005, the 404 was also applied to action=edit pages... We had a large number of reports from active editors that they were having trouble creating articles, with the edit page not loading properly. Since this was disrupting basic site activity, we ended up reverting it before we had a chance to really track it down -- none of the developers could reproduce it at the time. The size of our base HTML from even the simplest skin should be enough to avoid tripping Internet Explorer's "friendly error pages", and we were unable to track down any specific browser, ISP proxy, or other hypothetical problem source. If people do encounter problems once this goes live, it at least shouldn't affect primary wiki functionality while we reproduce and fix it -- hitting a raw page view for a nonexistent page is something that you usually have to jump through some hoops to do within the wiki. After things have settled a bit, we'll probably start using more 4xx and 5xx status codes for various error pages. -- brion

2 2

Re: [Wikitech-l] 404 status codes for broken links
by roan.kattouw＠home.nl 23 Dec '08

23 Dec '08

---- Kalan <kalan.001(a)gmail.com> schrijft: >> On Tue, Dec 23, 2008 at 07:59, Brion Vibber <brion(a)wikimedia.org> wrote: >> In r44919 I've gone ahead and reimplemented bug 2585, so a page view for >> a nonexistent page will return a "404 Not Found" HTTP status code >> instead of a "200 OK". > > Do links of type http://**.wikipedia.org/wiki/redlink to nonexistent > articles really happen that often? They have to be typed by hand, or > otherwise they will be action=edit&redlink=1, which redirects to a > 404ing page only in English Wikipedia and some other wikis, not > everywhere. They happen when third parties link to an article that is later deleted. When search engine crawlers follow such a link, the 404 will tell them it's a dead link. Roan Kattouw (Catrope)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l December 2008