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
-----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-----
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
>******************************************
>
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]]
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/
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
>******************************************
>
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
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 ;-) ]
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