Project:Forum/archive/2010

v This page is an archive of items from the Project:Forum page before it was switched to LiquidThreads.

Forum archives per year

2006 – 2007 – 2008 - 2009 - 2010

Older snapshots

Forum snapshots prior to the per year archives: 1 (2006-07-12) – 2 (2006-08-09) – 3 (2008-05-12) - 4 (2009-07-08)
The following old Talk:Main_page snapshots also contain some forum-like threads: 1 (2005-08-19) – 2 (2005-12-15) – 3 (2006-03-15)

Please don't post comments here! Do that at the Support desk or at Project:Village pump.

Article presentation in tabs

I believe what the articles in all wiki projects and specially in wikipedia, must be presented in tabs. The general data in tab 0 (general tab), with it's menu, and other tematics from article presented in other tabs.

What we win with this ?:

Send minor kb. of data when solicite a page. Only load data for tab 'General'.
More speed. If send minor data, before are the data presented.
Content more ordered. The relvant information appear en tab general, other information in others tabs.
Content more complete. Many wiki-editors get involved that such-and-such information is not important. But it is only his thought and to give him the reason contributes to a poorer article and with a very strict point of view on what it is and is not important. For example, many editors tell it what a article about a algorithm don't must to have implementations of code, why with the time, a large list of implementations (in each language), it occupies more space than the proper article. But this information is very estimated for all the users been interested in these topics.

What is interested in having more a very nice wikpedia at sight or have an as useful as possible wikpedia to the major group of possible persons?

I suggest therefore the incorporation of tabs at the wikimedia software, for to present articles. One easy form for edit content would be edited using a tag so: '|= title =|' or '=| title |=' when appear '|= .... =|' must be considered what the content from here go in other tab. General tab, don't need this tag.

Sorry my bad english... --79.109.222.212 19:02, 20 March 2010 (UTC)[reply]

Login Seguro

Estoy tratando de encontrar un login seguro al software mediawiki, no encuentro ninguna extencion que cumpla esa funcion. No puedo usar SSL. Algo del estilo Token hecho con javasript del lado del cliente y el token que sea un valor de sesion aleatorio (md5hash(password_cliente+token)=md5hash(password_servidor+token)). Agradezco su ayuda. --190.228.111.50 21:23, 12 March 2010 (UTC)[reply]

Wiki not loads doc-files saved in MS Word 2007 format 97-2003

Version MediaWiki 1.14.0 and 1.15.1. writes: file is corrupt or the wrong extension.Can you tell why this happens and what is the solution? --194.85.96.104 07:11, 19 January 2010 (UTC)[reply]

Russian MediaWiki.org

I propose to create a Russian language section of the site MediaWiki.Org.

It will be more convenient for Russian translators and editors. Original request on Meta:

I propose to create different local site of MediaWiki at http://ru.mediawiki.org/, making both in the language edition of Wikipedia for more convenient work on the site (the current system requires the use of English names with postfix /ru in the categories). --Grigol 20:15, 2 January 2010 (UTC)

Dorkin Maxim 21:47, 4 January 2010 (UTC)[reply]

note: request on metawiki was rejected Lvova 21:55, 4 January 2010 (UTC)[reply]

I'm against this, for four reasons: 1) MediaWiki.org is about the MediaWiki software, and all development on said software happens in English. This means that even in a non-English language wiki, there will be English page names (variable or script manual pages, for example). 2) The current language system works just fine. It takes roughly the same amount of work to add /ru to the end of an existing page as it does creating an entirely new page name. If you desire a page name in Russian for easier searching, you can create a redirect to the /ru page. 3) If we were to allow a Russian MediaWiki.org, then we would then have to allow a MediaWiki.org for each other language that requests it, which would very quickly become burdensome on the developers who speak those languages in order to maintain all of those wikis. 4) MediaWiki is being rapidly developed and this separation will make it difficult to ensure that the content for all languages reflects what is currently available. As of right now, translators can add the English version to their watchlist and translate changes accordingly. Having multiple wikis makes that significantly less feasible as the translator would then have to visit a different site to check for changes. --Skiz zerz 22:15, 4 January 2010 (UTC)[reply]
- I agree with Skizzerz. --Jack Phoenix _(Contact) 22:18, 4 January 2010 (UTC)[reply]
(edit conflict) There was a similar request for a German version here and on my talk page. My opinion is still the same: I don't see why we would need to split this wiki; this is just a "cosmetic" change as this wiki is for MediaWiki's documentation; not for encyclopedic content or whatever else. Creating multiple wikis would make maintenance tasks much more difficult ({{Languages }} automatically links to localised version, etc.) and would mean that admins need to check each wiki for maintenance tasks and requests rather than only this one. iAlex 22:20, 4 January 2010 (UTC)[reply]
I agree with Skizzerz and IAlex. Similar reasons are on the meta. --Kaganer 15:43, 5 January 2010 (UTC)[reply]
Strong oppose - MediaWiki is multilingual; it is not like wikipedia. And also per Skizzerz. Snake311 04:18, 9 January 2010 (UTC)[reply]
I see no advantages in further partitioning of WMF wikis, at least unless some hostility at existing wikis towards some group of users (e.g. Russian-speaking) was proven. English titles represent less significant discomfort to me than the need to check yet another watchlist, e.g. here. But there is yet another point. A global, widely populated community could generate more different approaches, all proposals will have more review and critic, and community will be less biased. Every non-global, split off wiki (no matter by language or by what characteristic else) will have less structure, less active users (even XX-speaking or belonging to somewhat else target audience), less review, which will result in poorer content. Incnis Mrsi 12:45, 12 January 2010 (UTC)[reply]
Comment. Some of these objections could be addressed through MediaWiki enhancements; e.g. a multi-wiki watchlist, a multi-wiki search feature configurable through Preferences, page existence detection for interwiki links, etc. There needs to be in general better cross-project integration of data. Then ideas like this will be more workable, because we will not sacrifice so many advantages of a unified wiki by splitting into multiple wikis. Tisane 12:27, 22 March 2010 (UTC)[reply]

broken links to dynamic pages

Users can be accused of doing it wrong numerous times. Links are often provided to point this out. Only serious conflicts end up on administrative pages. Over time those links stop working leaving a bunch of dead links along with either false or just accusations. The wiki software barely allows experienced users to even find the conflicts that are serious enough to be debated.

This flaw specially on highly populated wiki's like wikipedia allows users to seriously game the system. A lot of new users already find their talk page being templated quite offensive. If the links pointing to the debate are unavailable a honest person can only assume the accusations are just.

The page history and user contribution pages lack modern UI features. It is for example impossible to see that a user has been working at a specific article for years. This gives way to much credibility to editor ranks. A moderator who only looked at the article one time is not better informed about the topic while the interface does give this impression.

As many editors edit within a narrow scope of expertise such impression is always flawed. Likewise, an administrator might want to see who was contributing to an article and who have been deleting things from it.

For example/reference: On wikipedia I've seen people create articles and trying to work at them while others kept deleting perfectly sourced material from it and eventually deleting the entire article. It makes me wonder about the different standards for making the archive of deleted pages invisible and the censorship of the biography of living person. Why would the deletion debate even be preserved if the content it debates is not available? Perhaps (after deletion) the article archive should be merged into the deletion debate to make sure everyone looking over the topic is familiar with the validity of the arguments and to allow new editors to avoid re-creating an even worse version of the article.

This seems unrelated but it is just to explain how the current software allows edit warriors to elegantly cover their tracks while hard working contributors have nothing to show for their effort. Which was not the point I believe. To not have the links to dynamic pages in addition to this really renders a contributor without any defense. It would be nice if www.wiki.com/articlename#foobar in case this article section doesn't exist would trigger an archive search and redirect to the specific #foobar section on the correct archive page. This would add serious transparency to the process.

For clarification, I can easily write my own tools for this, new users are not helped by those.

Thanks for your time and good luck,

84.104.135.141 18:33, 9 February 2010 (UTC)[reply]

Box for Extensions with no development/maintenance

I think it could be useful to have a box to mark extensions which are not developed activly or witch are not maintained anymore. This may help to solve problmes, for example that someone does not use this extensions because they might get incompatible in future. --DaSch 22:06, 16 February 2010 (UTC)[reply]

Security of MediaWiki 1.15.1

So is there any fixes for the 1.15.1 or do I need downgrade to 1.15.0? --CheerYo

Insecure extensions

I propose to delete pages on extensions that had been marked with {{Security alert }} for some time (say, 6 months) and haven't been fixed. This, of course, excludes extensions specifically intended for non-public environments. Max Semenik 08:35, 25 February 2010 (UTC)[reply]

Sounds like a good idea. Happy‑melon 09:30, 25 February 2010 (UTC)[reply]

Why not keep the pages and leave it up to wiki owners to decide whether the extension is worth the security risk? Even if it would be inadvisable to use some extensions as is, they might be improved later, or the code cannibalized for use in other extensions. So it's better to keep those pages around, in case someone needs them. Tisane 10:53, 25 February 2010 (UTC)[reply]

I think the pages should not be deleted. The Security Alert is enough, the pages can be left on the wiki like Tisane said, for any further use. Administrators should know which extensions he could use in which enviorment and decide himself. And maybe someone will even find a solution and fix it. --DaSch

This raises an important issue, though - what standards do/should we have for allowing code for or documentation about an extension to be hosted on this site? Are there any minimum standards for usefulness/security/code readability/etc., below which the pages about an extension have to be removed from the site? Or is it pretty much anything goes? The old debates over eventualism vs. immediatism could come into play, of course. Tisane 04:59, 2 March 2010 (UTC)[reply]

Stuff in SVN is held to a higher standard. Anybody who can edit here can post some pseudocode and call it an extension, and that probably should stop. ^demon 13:51, 22 March 2010 (UTC)[reply]

Spam attempt

My extension page has been edited and some html was injected by a malicious user - here is the diff - http://www.mediawiki.org/w/index.php?title=Extension:Add_HTML_Meta_and_Title&action=historysubmit&diff=305893&oldid=299109

Please ban this user. Is this the right place to report? Владимир Радуловски 15:02, 27 February 2010 (UTC)[reply]

Problem rss/feed

RSS Feed

my feed display this error:

This page contains the following errors:

error on line 2 at column 6: XML declaration allowed only at the start of the document Below is a rendering of the page up to the first error.

where is this file? error on line 2 at column 6: XML

Thanks in advance!! --Rosaduarte 20:37, 27 February 2010 (UTC)[reply]

Your feed contains a newline before XML opening tag. Search for a PHP file that starts with newline before first <? - most likely, it's LocalSettings.php. Next time, please ask at Support desk. Max Semenik 21:13, 27 February 2010 (UTC)[reply]

It's also possible that you have a ?> at the end of a php file, as you might find if you create an extension by copying it from a website. It's probably easier to isolate by finding which "require_once" or "include" in LocalSettings.php causes it to happen --Skew 16:43, 24 March 2011 (UTC)[reply]

Hiding a category

Hi there. Don't you know how can be hide category in an article, which template has and this template is used in that article, thanks in advance –BRUTE ^talk 12:04, 2 March 2010 (UTC)[reply]

"Hello World"-type examples in documentation

I found Manual:Parser_functions#Example_parser_function_extension to be very helpful for writing my first parser functions. I think we should provide more simple examples for new developers. That will be easier for them than trying to look at a more complex example (e.g. FlaggedRevs) and search through sparsely-documented variables in the manual and through the code documentation just to get a grasp on how to implement something that is very basic. Of course, they will still need to use those resources to implement more advanced functionality, but it's helpful to have "hello world"-type examples as a starting point. Tisane 12:45, 22 March 2010 (UTC)[reply]

WikiProjects

Would this community be receptive to the formation of WikiProjects? E.g., there could be projects devoted to improving parts of Mediawiki.org, or to developing certain aspects of the code. It provides an easily-watchlisted location for collaboration on areas of interest to particular volunteers. Instead of ideas being scattered so widely across userspace and talk pages, where they often stagnate due to inattention by other users and competing demands for the idea generator's time, to-do lists and such can be put on a WikiProject page and people can coordinate to accomplish them. And the work can be done in a way that interdependent projects are managed with the big picture of the larger subject area in view. For instance, I would be interested in collaborating with others on cross-wiki integration, which encompasses potentially a large number of extensions. There could also be other major projects, consisting of lots of little sub-projects, that could benefit from a coordinated approach, such as developing code to combat spam, fight vandals, improve accessibility, implement access control to individual pages, etc. See Project:WikiProject Cross-Wiki Integration. Tisane 12:45, 22 March 2010 (UTC)[reply]

How do I get into discussion with devs?

Is there a way to start discussing with the devs of a specific extension beyond writing on the talk page? At Extension talk:LiquidThreads nothing happens after I posed a question that I deem very serious. Or is this just the aftermath of the Berlin conference and the travel issues? TIA --H-stt 06:18, 22 April 2010 (UTC)[reply]

See communication. Tisane 21:33, 26 April 2010 (UTC)[reply]

Extension Submission

Where can I submit the extensions I've made for others to use/download via Extension Matrix?

The extension matrix updates automatically every night. Tisane 21:33, 26 April 2010 (UTC)[reply]

Importing m:pywikipediabot

Would anyone have any objection to importing m:pywikipediabot and its subpages to MediaWiki.org? Tisane 21:34, 26 April 2010 (UTC)[reply]

In general I don't have an opposition as long as A) The people maintaining it there are ok with it, and B) They're willing to maintain it here as well. We get a lot of stuff dumped on Mediawiki.org and then forgotten, and I don't want the same to happen here. ^demon 00:39, 27 April 2010 (UTC)[reply]

It seems to me that it's better to use a PHP bot framework like w:User:ClueBot/Source anyway. Tisane 02:32, 14 May 2010 (UTC)[reply]

separating references from text -- awesome work

I dunno who made the code to separate the references from the text (as described in the Cite template documentation) but it is awesome! very very nice work. Decora 21:39, 11 May 2010 (UTC)[reply]

I propose a Extension:HarvardReferences to cite sources, Jimbo strongly supports it. Test sample is here. X-romix 13:14, 13 May 2010 (UTC)[reply]

(Resolved) Incorrect version number on Main Page.

The version number under current versions reads 1.6.12. Instead I am sure it should read 1.16.12. --Bigone5500 02:03, 29 May 2010 (UTC)[reply]

There is no 1.16.12. Tisane 02:12, 29 May 2010 (UTC)[reply]

Please visit the main page. Look at the box which has the title "Current Versions" and a download link. There is no version 1.6.12 that I know of... am I missing something? --Bigone5500 02:19, 29 May 2010 (UTC)[reply]

If I'm not mistaken, we continue to support 1.6 because it is the last version to use PHP4. See w:MediaWiki release history. See also Release notes/1.6. Tisane 04:38, 29 May 2010 (UTC)[reply]

I was looking at it wrong. --Bigone5500 20:26, 29 May 2010 (UTC)[reply]

Some other user posted this: --Bigone5500 03:09, 30 May 2010 (UTC)[reply]

Two questions. 1. I've installed 1.16.0beta3.tar.gz but it doesn't have the same looks as wikipedia.org (it looks less nice) why is this? 2. My wiki doesn't seem to support single carriage returns, whereas all other wiki's do?

Bot: or Tool: namespace?

It would seem that Manual: is used for bot documentation, e.g. Manual:MediaWiki-Recent Changes-IRCBot. Would it be beneficial to have a Bot: or Tool: namespace, much as we have an Extension: namespace, and reserve Manual: for the core? Tisane 07:56, 30 May 2010 (UTC)[reply]

A question about installation

This newbie has a question about installing MediaWiki: see the appropriate talk page. I may be missing something very obvious here. Cavila 12:21, 3 June 2010 (UTC)[reply]

(Resolved)Beta theme

How do I get the beta theme which appears in Wikipedia? I love it and I would want it to appear in my own wiki.

Hydriz 04:16, 4 June 2010 (UTC)[reply]

FAQ#How can I use Wikipedia's new skin (Vector) on my wiki?. Max Semenik 05:22, 4 June 2010 (UTC)[reply]

Pointers for following a wikimedia bug through to an en.wikipedia fix

Okay, please forgive me if the scope of this question goes slightly outside the remit of this site. I'm trying to follow bugs arising as a result of the Vector skin, through to their fixing in en.wikipedia. I grok the wikimedia bugzilla, and a bug such as 23541. And I can see this was resolved as code review r67839. But I can't make the jump from this to know whether en.wikipedia has updated the code version it uses to include this bug fix. Some pointers would be welcome, please. Where does en.wikipedia specify the code version it is running (or where is it specified)? And how do I tell which code review is incorporated in which code version? thanks. --Tagishsimon 19:01, 14 June 2010 (UTC)[reply]

Suggestion: Word counter in article history summaries as well

I think the word counter in our watchlists, showing how much an edit has added or deleted, are really great for giving an idea of what has been done to an article. I'd like to see such details for article histories (example of article history in current format) as well. Mikael Häggström 06:50, 30 June 2010 (UTC)[reply]

This is not the place to put feature requests. A short comment though: this will make history pages less readable. We put difference to recent changes because there's no previous revision listed nearby, but we have that in history, so if it were posted yo Bugzilla, I'd rather declined it. Max Semenik 07:49, 30 June 2010 (UTC)[reply]

This is the change in the number of bytes, not words. The numbers of bytes themselves are already in the page history. – rotemliss – Talk 13:26, 30 June 2010 (UTC)[reply]

All right. So Bugzilla would be the appropriate place to propose such a suggestion? Mikael Häggström 17:26, 30 June 2010 (UTC)[reply]

Yes, but you've been warned about its likely fate. Max Semenik 17:47, 30 June 2010 (UTC)[reply]

I think it would still look better than the current format, at least if overall additions were colored green and deletions were colored red. However, I think my request for more descriptive edit summaries would almost just as well be fulfilled by simply having the numbers showing the size of the article in green or red depending on the nature of the edit.Mikael Häggström 19:15, 1 July 2010 (UTC)[reply]

I would recommend you to post your proposal on strategywiki:. Diego Grez ^¡hablemos! 17:53, 1 July 2010 (UTC)[reply]

Thanks, I'll make a visit to that place. Mikael Häggström 19:15, 1 July 2010 (UTC)[reply]

My suggestion, somewhat changed, is now proposed at ~~strategy:Proposal:Red/Green coloring of article size numbers in article histories~~ bugzilla:24419. Mikael Häggström 19:32, 1 July 2010 (UTC)[reply]