Re: [Wikitech-l] testing of localization
On Mar 22, 2011, at 1:32 PM, Amir E. Aharoni wrote: > 1. Are there currently any tests in the MediaWiki test suite that > focus on localization? The MediaWiki PHPUnit test suites are still very much incomplete, and have yet to test a fraction of the MediaWiki code. That said, there are tests that test the wfMessage() function and the Message class, including the various translations. So if I am understanding your question correctly, the answer is somewhat yes. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Gender preference
prefstats maybe? On Feb 10, 2011, at 8:17 AM, Roan Kattouw wrote: > 2011/2/10 Andrew Garrett : >> That's not accurate. Aggregate preference data is available to >> toolserver users — the view omits the user ID field. >> > The view of which table? Running "SHOW TABLES;" on enwiki_p, I don't > see user_properties or anything else that looks like it might contain > preferences data. > > Roan Kattouw (Catrope) > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Minimum PHP now 5.2 in trunk (was: [Mediawiki-l] about requiring PHP 5.2)
On Jan 18, 2011, at 2:00 PM, Chad wrote: > +1 here. a::b syntax is less keystrokes having to use an array. Also > lets us remove the stupid hack from r68760[0] (probably similar things > elsewhere in the code) Can't forget the hack that is MWFunction::callArray, which is also a hack that is intended to fix PHP 5.1's incompatibillity. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Need some input
Ninjas > 9000. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How would you disrupt Wikipedia?
Of course, you have to remember that Wikipedia is a top 10 website. Wikia is a top 200 website. "hot article"s just don't scale that well to a wiki like Wikipedia. It's fundamentally flawed. On the flip side, an Etherpad-like feature would be nice. -X! On Dec 29, 2010, at 6:41 PM, Ryan Kaldari wrote: > I would steal some of the better ideas from Wikia like the "hot article" > lists, user polls, user avatars, and throw in some real-time > collaboration software a la Etherpad. > > Ryan Kaldari > > On 12/28/10 11:31 PM, Neil Kandalgaonkar wrote: >> I've been inspired by the discussion David Gerard and Brion Vibber >> kicked off, and I think they are headed in the right direction. >> >> But I just want to ask a separate, but related question. >> >> Let's imagine you wanted to start a rival to Wikipedia. Assume that you >> are motivated by money, and that venture capitalists promise you can be >> paid gazillions of dollars if you can do one, or many, of the following: >> >> 1 - Become a more attractive home to the WP editors. Get them to work on >> your content. >> >> 2 - Take the free content from WP, and use it in this new system. But >> make it much better, in a way Wikipedia can't match. >> >> 3 - Attract even more readers, or perhaps a niche group of >> super-passionate readers that you can use to build a new community. >> >> In other words, if you had no legacy, and just wanted to build something >> from zero, how would you go about creating an innovation that was >> disruptive to Wikipedia, in fact something that made Wikipedia look like >> Friendster or Myspace compared to Facebook? >> >> And there's a followup question to this -- but you're all smart people >> and can guess what it is. >> >> > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative to opendir() functions?
In the HISTORY file: * glob() is horribly unreliable and doesn't work on some systems, including free.fr shared hosting. No longer using it in Language::getLanguageNames() -X! On Dec 24, 2010, at 12:24 PM, Brion Vibber wrote: > Glob works too I think. > > -- brion > On Dec 23, 2010 12:06 PM, "Ilmari Karonen" wrote: >> On 12/22/2010 12:16 AM, Platonides wrote: >>> >>> We are only using opendir for getting a full directory list. >> >> That's a good point. Perhaps what we need is simply a utility method to >> list all files in a directory. >> >> In fact, I just realized that PHP already has one. It's called >> scandir(). Its only flaw IMO is that it doesn't automatically skip the >> current and parent dir entries, but you could always do something like >> >> $files = array_diff( scandir( $dir ), array( '.', '..' ) ); >> >> to accomplish that cleanly (or use preg_grep() to remove all dotfiles if >> you prefer). >> >> -- >> Ilmari Karonen >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative to opendir() functions?
> > Before going into too much detail on the thread, consider what you actually > need out of a fancy directory iterator. Offhand, I really can't think of > many places where that even *happens* in MediaWiki... maybe when purging > thumbnails? > I count 10 instances of opendir() exactly in trunk. > takes more > effort than just using things built into PHP (there's at least 3 or for > directory iterator systems already, including the opendir() stuff, the > object-oriented variant in the Dir class, and the SPL iterators). The main part of my push for this is that it isn't a new feature, but an easier way to read and write code. Myself, at least, readdir(), opendir(), etc is very arcane and confusing (same reason I don't use fopen, etc). RDI and SPL are even more confusing. I'm just going from ym own experience here, but I'm just thinking that it would be a good addition. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative to opendir() functions?
I'm not looking to integrate these frameworks entirely into MediaWiki; I'm just
talking about this one single file with one single class. (to be fair, it's 3
classes, but they're all in that one file).
-X!
On Dec 21, 2010, at 9:09 AM, Chad wrote:
> I hate these frameworks, so a big -1 from me.
>
> -Chad
>
> On Dec 20, 2010 11:22 PM, "Soxred93" wrote:
>
> Hi all,
>
> Recently, I've been working with the Symfony web framework [1]. One of the
> classes they include is called the sfFinder class [2], which is a fluid,
> easy-to-use file finder class. It searches for files or directories in the
> filesystem, using a fluid PHP 5 interface. It has no dependancies, so it
> should work fine with MediaWiki. After finding numerous instances of
> opendir(), readdir(), closedir(), etc. in MediaWiki, I thought that it would
> be a good idea to use one centralized class to do all file searching. There
> is only 1 potential issue I see, though. It is MIT licensed, which is GPL
> compatible, so it should be okay to implement it, but I'm not too clear on
> this issue.
>
>
> The usage is simple:
> sfFinder::type('file')->name('*.php')->in('/path/to/dir'); //list of PHP
> files in directory and all subdirectories
> sfFinder::type('file')->name('*.php')->in('/path/to/dir')->recurse(0);
> //list of PHP files in that directory only
> sfFinder::type('dir')->name('foo')->in('/path/to/dir'); //list of
> directories with the name "foo"
> There is documentation at [3], but it's for an old version. The code is very
> similar though, so most of it should apply to the current version.
>
>
> What would people think of a change like this. I would like to see this
> happen, but I'd like some more opinions before I look into implementing it.
>
> -X!
>
>
> [1] - http://www.symfony-project.org
> [2] -
> http://trac.symfony-project.org/browser/branches/1.4/lib/util/sfFinder.class.php
> [3] - http://www.symfony-project.org/cookbook/1_2/en/finder
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative to opendir() functions?
You can. But the main advantage is less writing, more understanding. I see
type('file')->name('*.php')->in('/path/') tp be easier to understand than
RegexIterator(RecursiveIteratorIterator(RecursiveDirectoryIterator('path/to/project/')),
'/^.+\.php$/i', RecursiveRegexIterator::GET_MATCH);
BUt we all have our own styles. I would like to see this included, even if
everyone doesn't use it. The current usage in MW isn't even RDI, it's just
opendir(), readdir(), etc.
-X!
On Dec 21, 2010, at 7:22 AM, Tim Starling wrote:
> On 21/12/10 15:21, Soxred93 wrote:
>> The usage is simple:
>> sfFinder::type('file')->name('*.php')->in('/path/to/dir'); //list
>> of PHP files in directory and all subdirectories
>
> You can use RecursiveDirectoryIterator to do that. There's a cute
> example in the online manual comments.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Alternative to opendir() functions?
Hi all,
Recently, I've been working with the Symfony web framework [1]. One of the
classes they include is called the sfFinder class [2], which is a fluid,
easy-to-use file finder class. It searches for files or directories in the
filesystem, using a fluid PHP 5 interface. It has no dependancies, so it should
work fine with MediaWiki. After finding numerous instances of opendir(),
readdir(), closedir(), etc. in MediaWiki, I thought that it would be a good
idea to use one centralized class to do all file searching. There is only 1
potential issue I see, though. It is MIT licensed, which is GPL compatible, so
it should be okay to implement it, but I'm not too clear on this issue.
The usage is simple:
sfFinder::type('file')->name('*.php')->in('/path/to/dir'); //list of PHP files
in directory and all subdirectories
sfFinder::type('file')->name('*.php')->in('/path/to/dir')->recurse(0); //list
of PHP files in that directory only
sfFinder::type('dir')->name('foo')->in('/path/to/dir'); //list of directories
with the name "foo"
There is documentation at [3], but it's for an old version. The code is very
similar though, so most of it should apply to the current version.
What would people think of a change like this. I would like to see this happen,
but I'd like some more opinions before I look into implementing it.
-X!
[1] - http://www.symfony-project.org
[2] -
http://trac.symfony-project.org/browser/branches/1.4/lib/util/sfFinder.class.php
[3] - http://www.symfony-project.org/cookbook/1_2/en/finder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
> > I think the idea that only people intending to do development work on > MediaWiki download from SVN is a bit insane. And as you note, these tests > are only going to grow in size over time. This whole discussion is bringing an analogy to a PHP framework that I'm using a lot now, symfony [1]. Their SVN is even larger than MediaWiki's. A large part of that is for languages (which, by the way, are not only languages, but every single culture too), and lots of unit tests. 99.99% of users don't need them, but they package them anyway. I think that the whole discussion should be moot, as 40MB is not that much in comparison to other codebases. Either way, people will need far more than 40MB of space on the server to run a good wiki, and not very many people have a server that would have less in the first place. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
It probably would not be too hard to make an extension to do just that. Just modify ExtensionDistributor. -X! On Dec 6, 2010, at 10:02 AM, Platonides wrote: > Niklas Laxström wrote: >> This suggestion seems to come up from time to time. I feel it is >> unrealistic. First of all we can't remove them from svn, since they >> have to be there. We could remove them from the tarballs, but please, >> last time I checked the tarball was hardly over 12 megs. Even with >> very slow modem it should take an hour at most to download that. Using >> better compression algorithm would likely shrink it as much as >> removing few languages. The minor languages don't even take as much >> space as the major languages, which usually have more complete >> localisation. >> >> Drawing the line is not easy and would likely cause continuous, >> unnecessary contention, put some languages in a privileged position >> and hurt MediaWiki's top notch i18n and l10n support. Each language is >> special, but you don't see that if you just look at the number of >> speakers. Do we really want hurt one of our greatest advantages? >> >> Besides, it feels silly to talk about this, while we simultaneously >> talk about including some of the most common extensions in the name of >> providing feature complete MediaWiki straight from the box--which is a >> goal I agree with. >> >> -Niklas > > A few days ago the issue came up where I was talking with an end user > who was complaining about MediaWiki being too large (in the server, not > in the tarball) compared to other apps like wordpress. > I think there's a use case for providing a mediawiki download where the > end user can check which languages they want and provide a custom download. > And/or document how to strip some languages from mediawiki. > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On Dec 6, 2010, at 5:12 AM, Niklas Laxström wrote: > On 6 December 2010 08:11, Q wrote: >> I think better time would be spent decoupling all the languages. Out >> the 57 megs for an svn export, 41 is the languages directory. Distribute >> the Big $foo, where $foo is some reasonable number of major languages, >> and offer the rest as a seperate dl. Perhaps an option would be to remove them from phase3, and moving them to a separate directory. Then, if someone switches the wiki language to some obscure language, or does &uselang=dfdjdkgj, or other activity that needs an obscure language, it would run a one-time download to the local filesystem. Might be too slow, but it's only a 1 time download. Just an idea. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] No more syntax errors!
With my limited svn knowledge I'd say no. Postcommit hooks are a part of svn itself, IIRC I could also be wrong. -X! On Nov 30, 2010, at 10:34 AM, Krinkle wrote: >> On Tue, Nov 30, 2010 at 10:19 AM, Chad >> wrote: >>> On Tue, Nov 30, 2010 at 10:04 AM, Chad >>> wrote: Hi everybody, It's kind of silly when we commit php syntax errors to SVN (I've done it too). Of course we should all test our code before committing, but sometimes we don't--especially when it's a one line change and there's No Way It Could Break. To help us stop making these silly mistakes (and to avoid the inevitable complaint and followup), I've added a pre-commit hook to SVN. All changed/added files ending in .inc/.php/.php5 are now checked with php -l prior to the transaction completing. You should get a fun error message on your local console if you commit bad code :) Let me know if you have any problems with it. -Chad >>> >>> Disabled temporarily, I'm hitting issues when doing >>> a svn del. >>> >>> -Chad >>> >> >> Syntax errors in the pre-commit file. >> >> Oh the irony. >> >> -Chad > > if/when this is enabled. Does this require anything from the commiters ? > Do I need to install something or run a command in addition to or > instead of 'svn commit -m "" ' ? > > Sounds nice as an additional check :) > > -- > Krinkle > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Balancing MediaWiki Core/Extensions
That seems like a good idea. I would love to see this in action. -X! Sent from my iPod On Sep 28, 2010, at 8:11 PM, Krinkle wrote: > Perhaps the new installer could contain that as an option during the > inital setup. > Like a two or three-column thing with a bunch of checkboxes. > > Language:English [\/] > Default theme(X) Vector (_) Monobook (_) Foobar > Common Extension:[X] ParserFunctions[X] SpecialInterwiki >[X] Cite.php[X] CharInsert >[X] CategoryTree > > etc. you get the idea > > Op 29 sep 2010, om 01:15 heeft Platonides het volgende geschreven: > >> Chad wrote: >>> On Tue, Sep 21, 2010 at 11:34 PM, Trevor Parscal wrote: when to move features out of core and into an extension or out of an extension and into core. >>> >>> I don't think anyone's commented on the former (everyone's been >>> talking about pushing in, not pulling out). IMO, the conditions for >>> splitting something into an extension >>> >>> A) Not a lot of people use it anyway (hard to gauge) >>> B) It probably shouldn't have been in core in the first place (eg: >>> AskSQL) >>> >>> So far, the only successful case I can think of offhand for splitting >>> an extension out was AskSQL, but it's a perfect example of what >>> should happen. >> >> DumpHTML was also split from core. texvc should have been moved out of >> core, but since that would change things set there from the >> mwbeginning, >> nobody did it yet. >> >> >> 1. This is a very valid and important goal, but am unconvinced and merging extensions into core is the only way to achieve it. We can, for instance, take advantage the new installer that demon is working on which has the ability to automate the installation of extensions at setup-time. >>> >>> Quick note on the installer. It only enables extensions that already >>> reside in your extensions folder. Since we don't distribute any with >>> the default package, this might not be terribly useful. More awesome >>> is Jeroen's GSoC work on extension management. Something to look >>> at post-1.17 branch though. >> >> I think the point is to start shipping mediawiki with common >> extensions >> there. >> >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committers
As did I. I expect to see some good work now, Jan Paul! But really, welcome! -X! On Aug 25, 2010, at 1:28 AM, MZMcBride wrote: > Tim Starling wrote: >> Extension access: >> * Jan Paul Posma (janpaul123): Sentence-level editing > > This is awesome. I really enjoyed the proof-of-concept. :-) > > MZMcBride > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New password hashing proposal
> On Thu, Aug 19, 2010 at 10:50 AM, Ryan Lane wrote: >> We could do a less secure, but more-secure-than-passwords >> alternative, >> which is to use email or SMS as a one time password device. SMS is >> obviously more secure than email, but would require us to ask people >> for their phone numbers. I don't do SMS, and I'm sure I'm not the only one who would rather not pay to get a password. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
I'm with Chad. That is simply AWESOME. It addresses yet another issue with usability, and it a well-done solution to it. -X! On Aug 9, 2010, at 7:00 PM, Chad wrote: > On Mon, Aug 9, 2010 at 6:55 PM, Jan Paul Posma > wrote: >> The last few weeks I've worked on some prototypes to illustrate >> this idea. >> You can find the most advanced prototype here: http:// >> janpaulposma.nl/sle/prototype/prototype3.html > > Can I just say that looks freakin' awesome? > > -Chad > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gartering extension-meta data
Or is wanted to get really hacky, preg_replace everything that is not part of the $wgExtensionCredits tag out and just send the tag to eval (). :) -X! On Aug 9, 2010, at 7:02 AM, Roan Kattouw wrote: > 2010/8/9 Jeroen De Dauw : >> Hey, >> >> I'm looking for a way to collect existing extension meta-data from >> the SVN >> repo and maybe also the extension pages on MediaWiki.org. Does >> anyone know >> of scripts/tools that already do this? >> > Depending on what metadata you need, the $wgExtensionCredits variable > could be your friend. Note that the extension doesn't need to actually > be installed: in most cases you can get away with just locating the > file that contains the $wgExtensionCredits assignment and require()ing > that file. This will probably fail in some cases, but most setup files > only contain assignments. > > Roan Kattouw (Catrope) > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in "View history" and "User contributions"
(just remember that it's 1.5 to 5 times slower, like I said earlier.
Whether or not that's an issue will have to be decided by higher powers)
On Aug 3, 2010, at 5:54 PM, Aryeh Gregor wrote:
> On Tue, Aug 3, 2010 at 5:09 PM, Daniel Friesen
> wrote:
>> Yup, though we might as well remember that not everyone has mb_
>> functions installed.
>
> if ( !function_exists( 'mb_strlen' ) ) {
> /**
> * Fallback implementation of mb_strlen, hardcoded to UTF-8.
> * @param string $str
> * @param string $enc optional encoding; ignored
> * @return int
> */
> function mb_strlen( $str, $enc="" ) {
> $counts = count_chars( $str );
> $total = 0;
>
> // Count ASCII bytes
> for( $i = 0; $i < 0x80; $i++ ) {
> $total += $counts[$i];
> }
>
> // Count multibyte sequence heads
> for( $i = 0xc0; $i < 0xff; $i++ ) {
> $total += $counts[$i];
> }
> return $total;
> }
> }
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in "View history" and "User contributions"
Just butting in here, if I recall correctly, both the PHP-native mb_strlen() and the MediaWiki fallback mb_strlen() functions are considerably slower (1.5 to 5 times as slow). Unless there's another way to count characters for multibyte UTF strings, this would not be a feasible idea. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Mediawiki-l] JetBrains PHPStorm License for MediaWiki Developers
Please, license? :) -Soxred93 On Jun 22, 2010, at 9:22 AM, Chad wrote: > For anyone who's not on the other list :) > > -- Forwarded message -- > From: Sam Reed > Date: Tue, Jun 22, 2010 at 8:47 AM > Subject: [Mediawiki-l] JetBrains PHPStorm License for MediaWiki > Developers > To: mediawik...@lists.wikimedia.org > > > Hi all, > I know we quite often get asked what IDE to use for PHP, and there's > mixed reviews and results. And not many solutions > > As such, JetBrains have recently released PHPStorm [1], and offer an > "open source license" (free license for open source projects, and I > have applied for and received one for the MediaWiki team. It's valid > for unlimited users, so any developer can have one. > > From this end, I've got a couple of queries. How can I distribute it > (to those who want it)? Obviously, I can't just post it on a wiki > page. Maybe OTRS or something? (To make it manageable) > > Also, they've requested we put a banner/similar onto a page. They > suggested I think, the Developer Hub [2]. Is this ok with people? > Something along the lines of an acknowledgement, and a logo, but I'll > get them to clarify it. > > People can email me for a copy of the license, till we get something > "more manageable", and I'll distribute it from there. I'd be > interested to see peoples views overall. I know their ReSharper and > dotTrace are very well recieved (of which I agree) in the .NET > community, so this should hopefully be of similar calibre. > > > Thanks > > > > Sam > > [1] http://www.jetbrains.com/phpstorm/index.html > [2] http://www.mediawiki.org/wiki/Developer_hub > > ___ > MediaWiki-l mailing list > mediawik...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AUTO: Naresh Kumar Nayyar is out of the office
*facepalm* On Dec 27, 2009, at 10:08 PM, naresh.kumar.nay...@us.elster.com wrote: > > I am out of the office until 12/29/2009. > > Hi, > > I am on vacation till 12/29/09. > > For any queries please contact Vinod Gundelli / Sean M Scoggins. > > Thanks > Naresh Nayyar > > > > > Note: This is an automated response to your message "[Wikitech-l] > Bugzilla > Weekly Report" sent on 12/27/2009 10:00:02 PM. > > This is the only notification you will receive while this person is > away. > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Webzzle
Wanna know the best part about Webzzle? It's blocked at my school. :) That'll surely help them... -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extensions in Bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chad wrote: > Hey all, > > I've compiled a list[1] of extensions in Bugzilla that don't have a > default > assignee. If you want to be (or should already be) the assignee for > any > of these, please let me know. Would like to really cut that list down > so bugs are getting triaged to someone who cares. Right now, they're > all being assigned to wikibugs-l, and we know how many bugs he > resolves :p > > -Chad > > [1] http://www.mediawiki.org/wiki/User:^demon/Unloved_extensions Add me to the Syntaxhighlight (GeSHI) and Interwiki, please. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpzVIMACgkQJj66ZG7fbBwy2QCcCrlkZYxnt4PZbKfVwfmhh1w5 ieMAn3TmOa01xPps0QPqvhA9/FEj7eVG =WoQC -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Log
I use this to make a log: Initialize log page: $wgLogTypes[] = 'newlog'; $wgLogNames['newlog'] = 'newloglogpage'; $wgLogHeaders['newlog']= 'newloglogpagetext'; $wgLogActions['newlog/newlog'] = 'newloglogentry'; Add new log entry: //Log it $log = new LogPage( "newlog" ); $log->addEntry( "newlog", $title, wfMsg( 'newlog-log' ) //or similar function ); Hope this helps, X! On May 16, 2009, at 12:37 PM [May 16, 2009 ], Jan Luca wrote: Hello, how can I create a log? Gruß Jan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l PGP.sig Description: This is a digitally signed message part ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
API buggy this week, eh? X! On May 10, 2009, at 11:00 PM [May 10, 2009 ], repor...@isidore.wikimedia.org wrote: Top 5 Bug Resolvers roan.kattouw [AT] gmail.com 15 PGP.sig Description: This is a digitally signed message part ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New preferences system
Keep in mind that when MediaWiki is developed, the best interests of Wikimedia are in mind. Wikimedia takes priority on MW development. X! On Apr 24, 2009, at 4:02 PM [Apr 24, 2009 ], Jacopo Corbetta wrote: Many wikis use MediaWiki beside Wikipedia. PGP.sig Description: This is a digitally signed message part ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] tran-subst-antiation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maybe something like {{Special:ExpandTemplates}}.
X!
On Apr 19, 2009, at 2:29 PM [Apr 19, 2009 ], Aryeh Gregor wrote:
> On Sun, Apr 19, 2009 at 2:16 PM, William Allen Simpson
> wrote:
>> It's hard to document ("subst" doesn't seem to translate well or mean
>> anything to many folks), harder to remember, and hardest to type:
>>
>> {{subst:TEMPLATE|P1|P2|subst=subst:}}
>>
>> I'm often forgetting that final parameter, and conscientiously
>> have to edit
>> again. Others don't bother subst'ing at all!
>>
>> Is there a solution proposed anywhere already?
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=2777
>
> It seems like this exists in an extension. I don't know whether the
> extension is good enough to enable on Wikimedia and/or just add to
> core; I haven't looked at it.
>
>> If not, here's my rough idea:
>>
>> Leading {{:: -- easy to type (already holding the shift key) --
>> same as
>> {{subst: -- only happens in edit parsing, no change to database.
>>
>> Leading {{## -- easy to type (already holding the shift key) --
>> obviously
>> must be different than {{:: -- used inside templates, tells the edit
>> parsing to "subst:" only subst'ing, otherwise ignored and treated as
>> concatenation. Same as C pre-processing operator.
>
> I think an actual keyword like "substall" is better. It's possible to
> Google the term to find documentation.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknrfWYACgkQJj66ZG7fbByrmACeIoJj8/0DAHKX6hfGwxapq8PG
OjkAn2nL/N9BIu+2r+arofsxLck1TMmG
=sCqA
-END PGP SIGNATURE-
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
People are so cruel... why can't they thank Werdna for his fine work on AF? X! On Apr 5, 2009, at 11:00 PM [Apr 5, 2009 ], repor...@isidore.wikimedia.org wrote: AbuseFilter 9 PGP.sig Description: This is a digitally signed message part ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] which test wiki is current with SVN?
The thing is, you should be sure that your commit doesn't break anything, so this shouldn't be too big a problem. -X! On Mar 31, 2009, at 10:26 AM [Mar 31, 2009 ], jida...@jidanni.org wrote: > What test wiki other than one's own runs the current SVN version? > Even test.wikipedia.org is "only" at r48811. > How does one confirm a problem is not just local before posting a bug > without waiting a few days for test.wikipedia.org to catch up? > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Upload-by-URL for test.wikipedia.org
Brion Vibber wrote: > I've enabled a test configuration of MediaWiki's upload-by-URL ability > on http://test.wikipedia.org/ > > The default configuration limits URL uploads to sysops, so for now > you’ll need to be a sysop on Test Wikipedia to try it out. If everything > seems fairly problem-free we’ll start rolling this out a bit more widely > for Commons and other sites. > > In addition to being able to handle large files without an ugly manual > download+reupload, the upload-by-URL functionality is also needed for > future-facing work Michael Dale is working on to allow an on-wiki media > picker to fetch freely-licensed files from Flickr, Archive.org, and > other places. > > We may want to consider improvements to UI and workflow, but it seems to > at least work. :) > > More at the Wikimedia technical blog: > http://techblog.wikimedia.org/2009/03/upload-by-url-for-testwikipediaorg/ > > -- brion vibber (brion @ wikimedia.org) > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > Recieved this when trying to upload a non-existant image: "The file is corrupt or has an incorrect extension. Please check the file and upload again." It could probably say a nicer message if the image does not exist, if it gets a 404. X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Abuse Filter extension activated on English Wikipedia
Cobi (owner of ClueBot) and his roomate Crispy have already been working hard to make this specific dataset, but they've been hurt by not enough contributors. The page is here: http://en.wikipedia.org/ wiki/User:Crispy1989#New_Dataset_Contribution_Interface X! On Mar 19, 2009, at 8:15 AM [Mar 19, 2009 ], Tei wrote: > On Thu, Mar 19, 2009 at 1:03 PM, Delirium > wrote: > >> Brian wrote: >>> This extension is very important for training machine learning >>> vandalism detection bots. Recently published systems use only >>> hundreds >>> of examples of vandalism in training - not nearly enough to >>> distinguish between the variety found in Wikipedia or generalize to >>> new, unseen forms of vandalism. A large set of human created rules >>> could be run against all previous edits in order to create a massive >>> vandalism dataset. >> As a machine-learning person, this seems like a somewhat problematic >> idea--- generating training examples *from a rule set* and then >> learning >> on them is just a very roundabout way of reconstructing that rule >> set. >> What you really want is a large dataset of human-labeled examples of >> vandalism / non-vandalism that *can't* currently be distinguished >> reliably by rules, so you can throw a machine-learning algorithm >> at the >> problem of trying to come up with some. >> > > since theres already a database, this sounds like could be done > flagging > edits as "vandalism", and then reading the existing database > information to > extract these details, like ip, a diff of the change, etc.. that > way, > humans define what is a "vandalism", and the machine can learn the > meaning. > > this may need a button or something, so users report this, and the > database > flag the edit > > > -- > -- > ℱin del ℳensaje. > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Abuse Filter extension activated on English Wikipedia
However, that simply disallows them all. On enwiki, the blanking
filter warns the user, and lets them go through with it after
confirmation.
X!
On Mar 18, 2009, at 4:51 PM [Mar 18, 2009 ], jida...@jidanni.org wrote:
> AG> frown on page-blanking
>
> For now I just stop them on my wikis with
> $wgSpamRegex=array('/^\B$/');
> I haven't tried fancier solutions yet.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia is full
What about replag? The bot would puke every time that replication stops. On Mar 10, 2009, at 8:02 PM [Mar 10, 2009 ], Robert Rohde wrote: > On Tue, Mar 10, 2009 at 4:43 PM, K. Peachey > wrote: >> On Wed, Mar 11, 2009 at 9:21 AM, Robert Rohde >> wrote: >>> Out of curiousity, when a technical problem shuts down all >>> editing on >>> a major wiki (as this did) are there any automated alerts? Is it >>> likely to be noticed and addressed even if no one rushes to IRC? >>> >>> I guess I am curious what is the normal delay between problem onset >>> and problem recognition? >>> >>> -Robert Rohde >> I believe with this issue (Full MySQL table) that there is no easy >> way >> to automate the test. >> maybe you could automatically query it every so often but even then >> that might not return reliable results. > > One could query count(*) from revisions (or some similar artifice, > such as looking at the recent changes feed) and trigger an alert if it > stops increasing. > > Such things are probably totally unnecessary on enwiki, because there > is no shortage of people to complain, but I could image it might be > useful to have such an alert for smaller, non-English speaking wikis. > > -Robert Rohde > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia is full
In case you didn't see the whole StatusBot fiasco on enwiki, I used to run a bot as a replacement to a replacement of [[User:StatusBot]]. The bot made 50k edis in a few months, and was soon shut down by Brion. A bot the edits the sandbox every few minutes would no way be approved. On Mar 10, 2009, at 7:54 PM [Mar 10, 2009 ], Thomas Dalton wrote: > 2009/3/10 K. Peachey : >> On Wed, Mar 11, 2009 at 9:21 AM, Robert Rohde >> wrote: >>> Out of curiousity, when a technical problem shuts down all >>> editing on >>> a major wiki (as this did) are there any automated alerts? Is it >>> likely to be noticed and addressed even if no one rushes to IRC? >>> >>> I guess I am curious what is the normal delay between problem onset >>> and problem recognition? >>> >>> -Robert Rohde >> I believe with this issue (Full MySQL table) that there is no easy >> way >> to automate the test. >> maybe you could automatically query it every so often but even then >> that might not return reliable results. > > A bot that edits the sandbox every few minutes would work, would it? > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New SVN committer
Welcome, aphid! Soxred93/X! On Jan 29, 2009, at 4:25 PM [Jan 29, 2009 ], Brion Vibber wrote: > Added aphid (aphid.org), working on MetaVid. > > -- brion > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Article blaming
It's more of a starting point, to flag editors who may have made the edits. All that would remain is looking over if that user did in fact make that edit (and if they didn't, it's back to square 1) On Jan 26, 2009, at 3:38 PM [Jan 26, 2009 ], Gregory Maxwell wrote: > On Mon, Jan 26, 2009 at 1:41 PM, Robert Rohde > wrote: > [snip] >> When the license calls for attribution to be treated in a >> "reasonable" >> way, I suspect that one could make a good case that relying on a good >> blame engine would often generate a reasonable attempt at >> attribution, > [snip] > > Often, sure— But what happens when it fails and you have someone > yelling loudly on the talk page "Hey! it's misattributing my > authorship to some dumb bot, yet I wrote the whole thing!" ... > > It's not reasonable by any human (or legal) standard to continue to > misattribute in a case like that, yet addressing that case with some > automatically generated report is not easy. > > (and, of course, it's a great starting point… so long as someone > remembers to continually point out that its not a final answer). > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafts extension in testing
After trying it out on testwikipedia, I am very impressed. This is a feature I have long been waiting for, and it's finally a reality. :) Is there an estimate as to when this may go live on WMF servers? Soxred93/X! On Jan 16, 2009, at 7:38 PM [Jan 16, 2009 ], Brion Vibber wrote: > Ok, things are finally starting to normalize as far as getting away > from > fundraiser craziness, preparing regular releases, and generally > getting > on with making things better for users! > > I've enabled the Drafts extension for testing on > http://test.wikipedia.org -- this little cutie was new staff dev > Trevor > Parscal's first assignment here, but deployment got pushed back > when we > went full-steam on fundraiser banner stuff. > > > I've written up a quickie blog post with some purty screen shots: > > http://leuksman.com/log/2009/01/16/drafts-extension-enabled-on-test- > wikipedia/ > > > Suggestions for improvements to the UI and workflow are always > welcome! > > -- brion > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] api file uploading
https://bugzilla.wikimedia.org/show_bug.cgi?id=15227 On Jan 7, 2009, at 10:27 PM [Jan 7, 2009 ], Daniel Friesen wrote: > Second that. Being able to create extensions which handle uploading in > widely different ways would be very useful. I'd love something that > combines the Upload form with Semantic Forms. > > ~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) > > > > Chad wrote: >> On Wed, Jan 7, 2009 at 6:31 PM, Michael Dale >> wrote: >> >> >>> For use in both the external media wizard >>> http://lists.wikimedia.org/pipermail/wikitech-l/2009-January/ >>> 040858.html >>> >>> and the firefogg in-browser transcoder & up-loader /with progress >>> bar/: >>> https://bugzilla.wikimedia.org/show_bug.cgi?id=16927 >>> http://lists.wikimedia.org/pipermail/wikitech-l/2008-December/ >>> 040524.html >>> >>> We could really use the addition of file uploading support to the >>> API. >>> This would also be helpful for cell phone image type applications >>> no? >>> >>> Is there anyone actively looking into such a development? Any >>> tips if I >>> take that on? >>> >>> >>> peace, >>> --michael >>> >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >>> >> >> I think the thing in the way of this is a better upload system (less >> integrated with Special:Upload). I know Bryan was working on >> it for awhile, dunno where he is on it these days. >> >> -Chad >> > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
I think that's the error... On Jan 4, 2009, at 10:00 PM [Jan 4, 2009 ], repor...@isidore.wikimedia.org wrote: > December 29, 2009 - January 05, 2009 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Subpage titles
Hopefully, if the new DISPLAYTITLE functionality goes into effect, the effect of this can be done. X! On Dec 29, 2008, at 9:59 PM [Dec 29, 2008 ], K. Peachey wrote: >> Then it wouldn't be possible to link to the page by copy-pasting the >> page title, which we've always been very careful to make sure it's >> been possible to do. I'm not saying this is prohibitive for wikis >> like Wikisource that rely so heavily on subpages, but it's something >> that needs to be kept in mind. What would be the best way to address >> that? Ignore it? Allow " » " as an alternate subpage separator? > Maybe have a little button in the right/opposite corner that you click > and uses js magic to copy it to the clipboard maybe? > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IBM DB2 patch for MediaWiki
That's disgraceful. I might have to boycott phpBB just because of
that...
Soxred93
On Dec 24, 2008, at 2:36 PM [Dec 24, 2008 ], Chad wrote:
> That's just disgusting
>
> On Dec 24, 2008 2:35 PM, "Aryeh Gregor"
> >
> wrote:
>
> On Wed, Dec 24, 2008 at 2:19 PM, Daniel Friesen
>
> wrote: > Agh n don't...
> I just looked, and you're right, they seem to rely on things like this
> for multi-DB support:
>
>/**
>* Oracle specific code to handle it's lack of sanity
>* @access private
>*/
>function _rewrite_where($where_clause)
>{
>
> preg_match_all('/\s*(AND|OR)?\s*([\w_.]++)\s*(?:(=|<[=>]?|>=?)\s*
> ((?>\'(?>[^\']++|\'\')*+\'|[\d-.]+))|((NOT
> )?IN\s*\((?>\'(?>[^\']++|\'\')*+\',? ?|[\d-.]+,? ?)*+\)))/',
> $where_clause, $result, PREG_SET_ORDER);
>$out = '';
>foreach ($result as $val)
>
> Probably not a model we want to follow, although I don't think that
> using raw SQL is necessarily bad in principle (using string
> concatenation to include variables certainly is, though).
>
> ___ Wikitech-l mailing
> list
> wikitec...@lists.wikimedia
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Anchors haven't id attribute
But then the anchors would change if a section is placed above it,
breaking links.
Soxred93
On Dec 19, 2008, at 10:03 AM [Dec 19, 2008 ], Sylvain Brunerie wrote:
> 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 "> class=\"mw-headline\">$text";
>> }
>>
> (Tell me if I'm wrong.)
>
> — Sylvain Brunerie
> [[w:fr:User:Delhovlyn]]
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikiEN-l] Suggestion on how referencing system could be improved
I'm also forwarding this to the wikitech-l list. On Dec 3, 2008, at 8:46 PM [Dec 3, 2008 ], Thomas Larsen wrote: > Hi all, > > The current .. system produces nice > references, but it is flawed--all the text contained in a given > reference appears in the text that the reference is linked from. For > example: > > It was a sunny day on WednesdayDavid Smith. ''History of > Wednesdays.'' > History Magazine, 2019.. The next day, Thursday, was cloudy. > > == References and notes == > > > > (That's a very simple example, too. References start to become a lot > larger once they start to include other information and/or are > produced via a template.) > > Once way I could conceive of correcting the problem is to have a > reference tag that provides only a _link_ to the note via a label and > another type of reference tag that actually _defines_ and _displays_ > the note. For example: > > It was a sunny day on Wednesday. The next day, > Thursday, > was cloudy. > > == References and notes == > > David Smith. ''History of Wednesdays.'' > History > Magazine, 2019. > > This makes the raw wikitext easier to read, since the text of the > actual reference is in the _references_ section instead of in the > page's primary content. > > I think this could work ... > > --Thomas Larsen > > ___ > WikiEN-l mailing list > [EMAIL PROTECTED] > To unsubscribe from this mailing list, visit: > https://lists.wikimedia.org/mailman/listinfo/wikien-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
