Wikinews:Water cooler/technical/Archive/6

Techniques used to keep news down after edits

I wonder what technique WikiNews uses to keep a news message down after a (small) edit; for example, if one edits a news message originated on August 8th, the message doesn't go up again over messages published on August 9th. I realize the DynamicPageList extension checks when news is first added to the published-category, but on my Wiki this ccategory timestamp (cl_timestamp) is updated when I edit a page. Is there a technique I can use or should I edit the PHP itself?

The solution is to make sure you're running MediaWiki 1.5, which keeps the articles in categories across edits. If you are running MediaWiki 1.5, then make sure you've got the latest DynamicPageList extension. If you're still having a problem, please leave a message on my talk page and I'll try to work with you to fix the problem. -- IlyaHaykinson 16:49, August 9, 2005 (UTC)

Problems in IExplorer

The Portuguese version of Wikinews doesn't work with IExplorer, although it is ok with Mozilla and Firefox. I have changed the skin, however I don't know how to fix yet. Someone have an idea? I would be very gratefull. Thanks. --Carlosar 22:04, 5 August 2005 (UTC)

What a surprise: IE doesn't work with an open-sourced web page. <insert "phony, surprised look on my face" here>. Seeing as how Paul Thurot has called for a boycott of IE, I would say that best thing to do here would be... nothing! Don't fix it or even try to fix it until Microsoft gets off their collective ass and implements full CSS compliance. Paul Thurot's call for a IE Boycott can be found at http://www.windowsitpro.com/Article/ArticleID/47208/47208.html Please note: I am NOT Paul Thurot, although I agree in principle with his call for an IE Boycott

• Enough of that "ditch this" or "ditch that" movements, they're really a waste of time. IE has some issues with CSS rendering, and that's most likely your problem. Hopefully when 7.0 comes around, the issues will be fixed. As of now, however - there is little anyone can do to fix the problem (besides the developers for MediaWiki, in which case I send them blessings for it will not be a fun job). --Mrmiscellanious 15:33, 7 August 2005 (UTC)

Automatic things need work

Those Dynamic page lists need a little work, to avoid embarressing stuff. On religion Pope to leave hospital is listed multiple times on the page. Is there no way to tag old articles with a "do not display" code, so things don't display? I'm not against old articles, just now inaccurate ones. -- user:zanimum

Portal namespace

I moved all Wikinews portals back over to the new portal namespace. This was approved by the community in July. Eloquence has been kind enough to type up a list of the benefits of the Portal namespace:

1. One reason for putting portals in the Portal: namespace is to have a separate article count. We often publish the overall number of articles. But this includes the ever growing number of portals and is therefore misleading.
2. It also affects the Special:Allpages display. If I can filter by namespace, I no longer have to view these pages when looking at articles.
3. Fundamentally, namespaces have meaning. If we do violate that meaning, we're going to run into problems in other areas where it is interpreted. For example, if, using Wikidata, we attach a schema to the article namespace, so that we could have a "date" and a "sources" field. Then this would also be added to the portal pages. (Namespaces are linked to schemas in Wikidata.) There are also filters for Special:Recentchanges and User Contributions that work by namespace, and new filters like that will likely be added soon. So it's not a good idea from an architectural point of view to overload the semantics of a namespace.
4. It simplifies the process of creating portals, and filtering them from relevant lists, as there has to be no awareness of the category system. Just putting the page in the right namespace is sufficient.

-- NGerda 00:37, August 12, 2005 (UTC)

Sorry, as far as I am aware Ilya, Vask and I still object. No consensus was found. Reverting. Dan100 (Talk) 09:29, 12 August 2005 (UTC)

Just remind Nick, who's obviously forgotten while on holiday:

I've read through this discussion again and I don't think the case for such a namespace is pretty strong is true, really. The number of topic pages compared to articles is *tiny* and I don't think the develop tag is going anywhere - not least because it tells people what needs to be done and how to publish articles. So what other reason justifies it? On the other hand, it's a *massive* job to make this change properly and no doubt it will be me who has to pick up the pieces when someone makes a half-arsed hash of it. So I oppose this, completely. Dan100 (Talk) 15:23, 20 July 2005 (UTC)

I know this is going over somewhat established territory, but, please tell me, why do we need the Portal namespace? I thought we were pretty happy with Category:Portal. -- IlyaHaykinson 04:09, July 21, 2005 (UTC)

The reason is currently some portal like page, like Main Page, or regional portal are placed on main namespace and counted as "article". It affects statistics when we count the number of articles, or examine "long pages" list. Category is namespace to categorize pages, and you can't tune where article list under a category appear. Portal namespace with more frexibility on design might be happier in my opinion. --Aphaia 06:56, 21 July 2005 (UTC)

We've, what, 2,500+ articles? The dozen or so region/topic pages are a drop in the ocean.

Furthermore, seeing "Portal:" before the title is weird and potentially confusing to readers. Plus it means having to prefix that before putting (eg) United States into the search box. What's the point in that?

This is change for changes sake, and positively harms the project. It should not be done. Dan100 (Talk) 10:23, 21 July 2005 (UTC)

We can always pull up statistics by making a database query. We can have a DPL that outputs a numbered list that doesn't include things in Category:Portal. I think that the portal namespace is worse than a category for three reasons:

1. The name of the page is confusing, "Portal:Africa" looks worse than just "Africa"
2. Search will not automatically show portals
3. The URLs are harder to give out. Instead of http://en.wikinews.org/wiki/Africa, it's got an extra "Portal:" in there.

I think with the DPL having more functionality now, it makes little sense to have the separate namespace. -- IlyaHaykinson 13:17, July 21, 2005 (UTC)

Ilya, those are exactly my concerns. We must put our readers first (or what's the point?). There is no consensus for such a namespace. Dan100 (Talk) 16:04, 21 July 2005 (UTC)

• In order to show my opinion: I agree with those opposing a seperate namespace för Portals. The little benefit of more accurate statistics doesn't respond to the cons, like simpleness of likning ([Africa] instead of [Portal:Africa|Africa]), better URL:s (as mentioned), better page header etc. The localism (making portals for every town, which I support) and "topicalism" (making portals for every topic, which I also support) could be done without the namespace. Väsk 21:50, 22 July 2005 (UTC)

It is apparent that NGerda needs to go and learn what consensus is. Dan100 (Talk) 10:16, 12 August 2005 (UTC)

Please stop attacking people with which you disagree, Dan100. There's no need for that last statement about NGerda. Attack the idea, not the person that came up with it. I have seen no reason to doubt NGerda's motives in this process. - McCart42 (talk) 13:04:21, 2005-08-12 (UTC)

Dan100: A majority of participants I have spoken with would prefer to use the portal namespace. There are a range of reasons, but let me address those you have c/p above firts:

The DPL can manage using the Portal category.

The DPL max categories will need to be increased to manage the longer, more complex cat/notcat searches. Simplicity is, of course, always faster and less loading on the database, so should be preferred over the longer, more complex.

Longer, more complex url required.

Current searches will find the redirects to the new Portal: pages; you don't need to use the longer urls. /wiki/Africa will find /wiki/Portal:Africa.

Search will not find portals

As it shouldn't, since they are not news articles. However, that can easily be altered to add the Portal namespace to the default list of namespaces searched - then they would be found.

DPL has the necessary functionality.

It does, but at a small and unnecessary cost.

Ease of linking ([[Africa]] instead of [[Portal:Africa|]])

Again, there is a redirect in place so [[Africa]] will link directly to [[Portal:Africa]].

There are several reasons for the use of the Portal: namespace which I consider to be valid:

• Remove non-articles from the main namespace. (Statistics and uniformity)
• Provide a clearly identified space for local portals/wikibureaus. (Uniformity, ease for new users)
• Allow simple developing articles searching.

  This is, of course, my personal reason for suggesting extensions to the DPL in the first place. Consider:
  
  <DynamicPageList>
  notcategory=Published
  namespace=0
  </DynamicPageList>
  
  Which will locate any article which has not been published yet, if we move Portals out of the main namespace.

In short, I don't see the above objections as reasonable. - Amgine/^talk 22:30, 12 August 2005 (UTC)

I ask everyone to please visit here. Eloquence and Amgine have outlined why the portal namespace is necessary. I made a very time-consuming attempt yesterday to make local reporting viable on Wikinews, spending hours working on navigation templates and such. When Dan reverted the portal namespace moves, it completely messed up all of my work. It would be great if Dan and others would help out on improving local Wikinews portals instead of sabotaging attempts to do so. -- NGerda 23:44, August 12, 2005 (UTC)

I would like to disagree once more with the Portal namespace. I think it's a solution in search of a problem.

The DPL can manage using the Portal category.

The DPL max categories will need to be increased to manage the longer, more complex cat/notcat searches. Simplicity is, of course, always faster and less loading on the database, so should be preferred over the longer, more complex.

Increasing the max categories is not difficult. It has not shown to place an undue load on the database.

I did not say undue. I said unnecessary. - Amgine

Longer, more complex url required.

Current searches will find the redirects to the new Portal: pages; you don't need to use the longer urls. /wiki/Africa will find /wiki/Portal:Africa.

Simple, clear URLs are key to a well functioning Internet. I do not see any reason to have "Portal:" other than some percieved problem of needing to count articles. If they're linked as [[Portal:Africa]] in some places and [[Africa]] in others, people will end up linking to two different URLs containing the same content — which is against the concept of a unique identifier for a piece of content.

Alias. Also, it is currently the practice on all WMF sites to use redirects; are you suggesting this be done away with? - Amgine

Search will not find portals

As it shouldn't, since they are not news articles. However, that can easily be altered to add the Portal namespace to the default list of namespaces searched - then they would be found.

It's not a "search for articles", it's a "search". If I type "Topeka" I hope to find the Topeka, Kansas portal in the results.

Which will be the case if Portal is added to the default search namespaces. - Amgine

DPL has the necessary functionality.

It does, but at a small and unnecessary cost.

I think it's definitely no larger of a cost than the adding of Portal: to the title of these pages. A portal is a door — and these aren't doors! Please familiarize yourself with the definition of portal; even the web-related definition there is much different than our use of the term.

You were correct. However, I found this precise usage in the American Heritage Dictionary, the Merriam Webster's Dictionary, several medical dictionaries, and the Free Online Dictionary of Computing, so I added it to the Wiktionary definition. A portal is an entryway, and even specifically defined as a topically-oriented knowledgebase, such as a collection of links to articles about a given topic. - Amgine

Ease of linking ([[Africa]] instead of [[Portal:Africa|]])

Again, there is a redirect in place so [[Africa]] will link directly to [[Portal:Africa]].

But then why have it in the Portal namespace?

For the other reasons mentioned - ease of identification, allowing more accurate statistics, and simplifying main page DPL calls. Here's an equally valid question: Can you give a reason why not? (dismissing other's reasons without argument does not invalidate them) - Amgine

Still nobody addressed the weird title that people see, nor the need for this for any reason beyond counting articles (which would mean decreasing usability and increasing complexity for the sake of some internal numbers). I don't want to continue to disagree forever though — is it time for a vote? -- IlyaHaykinson 00:23, August 13, 2005 (UTC)

My main reason for supporting the separate namespace is that it easily distinguishes portals from articles. -- NGerda 00:27, August 13, 2005 (UTC)

I have not seen an accurate statement as to how using the Portal: namespace will either decrease usability or increase complexity. There has already been informal voting in June, it appears. Wouldn't those who oppose a new implementation continue to ignore another on-wiki public commentary or poll? By an informal count (and excluding neutrals) at that time there were at least 5 in favor and at least 3 opposed. At this time already there have been 3 in favor and 2 opposed. - Amgine

Oppose. For those of you who know me as a dummy on this issue, I spent a considerable amount of time trying to come up to speed. I believe the Portal:| namespace idea is an inelegant idea that grates against common sense naming conventions. Non-programmers like myself confuse easy, and I do not believe the shift would shield no-nothings like myself from internal naming complications created by the move. The benefits of gaining some statistics more easily can likely be overcome through a "not-high" cost of developing software search techniques or a big server strain. 'Topics' and 'Regions' are intuitive, 'Portals' are potholes you gotta kick yourself out of every time you run over one.

Here is an vote re-cap up of course to the time of this posting (plus my new one) that I was worked on:

Suport = Eloquence ( easier article count, reduce dependency on DPL )

Suport = RossKoepke ( Maintenance, database, user-friendliness, future scalability )

Suport = NGerda ( localism )

Suport = Davodd ( localism )

Suport = Amgine ( database ease, current user friendly answerable with redirect )

Suport = Aphaia ( a watcher here, and I may be way wrong, but --> has similar proposal at Wikimedia )

Oppose = IlyaHaykinson ( no purpose )

Oppose = UncleG ( never said so outright, but --> 'regions' can be portals, currently user friendly )

Oppose = Dan100 ( currently user friendly, mess to clean up after )

Oppose = Vask ( 'regions' and 'topics' are sufficient )

Oppose = Edbrown05 ( naming convention ugly, confusing )

Abstain = Lief ( until it gets really local, then support at that level )

Abstain = CmWhite ( 'topics' can be portals (( Quakers )), current system user friendly )

I hope nobody is misrepresented. And of course this is not meant to represent the final position of anybody on this issue. -02:11, 13 August 2005 (UTC)

I would dispute this count. At least as much as I would dispute the characterizations. - Amgine

Fair enough objection, not specific though, nor could it be. I do belive this should come to a vote to get it over with. I guess that is my true motivation. -Edbrown05 02:37, 13 August 2005 (UTC)

Restore my comment. I said I wouldn't revert myself anymore... just couldn't understand why my siggy didn't post above and Amgine in near time frame thought he was replying to Ilya. So after a walk away, I reverted the revert of the above post.

But the point is that this is poison bullcrap to come on site seeing a revert war going back and forth all over again. Before it was DPL. Now it's Portal. Freakin' newsie hotheads or sumthin' -03:52, 13 August 2005 (UTC)

Regarding the argument that there aren't many portals and there are many news articles, this could change quite drastically if we start making portals for every neighbourhood in the United States to attract citizen reporters. The number of localized portals can easily exceed the number of news articles on the site. If we keep portals in the main namespace, this might dissuade people from creating them for fear of affecting the article count, "cluttering" up the list of pages, the recent changes, and so forth. (And while yes, you can do manual counts, I have enough experience with this from the Commons to know that this is not viable in the long run -- too many statistical processes rely on the simple counting procedure by namespace, including Erik Zachte's wonderful Wikistats.) I believe that this is one of the key reasons advocates of localism support this change: to encourage the creation of local portals without repercussions.

One point I made on IRC and which was copied here by Nick seems to have gotten lost in the discussion. Namespaces have one key advantage over categories: There is a very limited number of them. This is what makes them usable in a number of UI elements, such as Special:Recentchanges, Special:Allpages, Special:Search, Special:Contributions, and so forth. All these special pages allow to filter by namespace, but not by category.

Because whether a page is a portal or not is a fundamental distinction on the type of page, it makes sense to use a new namespace for it rather than a category, and enable the use of all of the above existing filtering mechanisms. Unlike saying "This is a news article about Google" or "This is a portal about a country", we are saying: This is a news article (no namespace). This is a portal (portal namespace). The distinction is more fundamental, and the examples given (existing MediaWiki features that make use of namespaces, article count) demonstrate that there may be more future cases where this distinction is important.

To give you one example of such a future case, I'm presently working on Wikidata, which is directly tied to namespaces (see Wikidata/Notes). In Wikidata, a namespace will be associated with a table schema, so we can add new fields to a page beyond a simple text field. In Wikinews, this would allow us to, for example, add a "publication date" field as well as a "sources" table relation to the article namespace, so you could have an easy user interface for the publication date and sources and wouldn't have to make use of ugly template syntax. But if portals are mixed with regular articles, the semantic distinction is lost. Categories cannot be associated with table schemas, and this wouldn't make sense, as they are too fluid (changing a schema on existing data is problematic as it could lead to data loss).

So, from an architectural standpoint, it makes a lot of sense to use namespaces on the level of the fundamental distinction between news articles or not-news articles, even if superficially, categories may appear to be a simpler solution to the same problem. I strongly suggest using the Portal: namespace rather than categories for this reason. I hope those opposing the change will consider these arguments, and that we can move this discussion from the level of interpersonal conflict to a careful weighing of the advantages and disadvantages of both approaches, including long term consequences.--Eloquence 04:15, 13 August 2005 (UTC)

This idiot couldn't resist picking out of Eloquence comments:

"Unlike saying "This is a news article about Google" or "This is a portal about a country", we are saying: This is a news article (no namespace). This is a portal (portal namespace). The distinction is more fundamental."

"So, from an architectural standpoint, it makes a lot of sense to use namespaces on the level of the fundamental distinction between news articles or not-news articles... "

-68.232.153.54 05:35, 13 August 2005 (UTC)

Edbrown05 goes to the library and asks at that help desk for stories on Africa. With a smile by the desk assistant, a list is printed and handed to him.

Edbrown05 sits down to examine the search results and is extremely pleased.

Thinking that Africa sounds like an interesting continent, Edbrown05 returns to the library help desk and asks for a print out on North America so he can compare reporting activity in the two. The library assistant, realizing that his work may be cut out for him today, returns with a print out.

Glancing at the print out and before losing the attention of the assistant, Edbrown05 asks what is a portal?

With a sigh, the assistant returns with this. Edbrown05 asks, “Okay, can you please make a print out on North America for me?”

“You already have it.” said the assistant.

-Edbrown05 20:05, 14 August 2005 (UTC)

• Damned good point, Ed. Dan100 (Talk) 11:16, August 17, 2005 (UTC)

"Okay, then may I have the North American category of this page please."

"Sure said the assistant, but we are out of ink for the printer. So if you go here you can view it." -Edbrown05 20:38, 14 August 2005 (UTC)

I would drop all my objections in exchange for the implementation of a user-friendly title for the page: making it say "Africa" or even "Africa Portal" or really anything more readable than "Portal:Africa" which is begging for a space, or something more logical. -- IlyaHaykinson 21:14, August 14, 2005 (UTC)

I'm really glad this has come back to the watercooler so we can really work it out before making time consuming changes/reverts. I'm also glad that everyone is setting out the arguments clearly to help our understanding.

• A category is simply a tool to organise articles, excitingly an article can have any number of categories.
• A portal is a gateway to read and organise articles on one particular category.

Simply changing categories to portal:categories, which is fairly meaningless and difficult to find. If all we want to do is view all the articles on a category, we can go to category:category and see them. 'Portal' in itself is not a category as such, it is a page. Portals are something more developed. While the categories means that they can 'manage' themselves automatically and look good with no human input, we have scope for a whole lot more. Therefore, I think, it does make sense for them to be in a namespace of their own. This allows for development of any portal without cluttering the main article space, for example Portal:Category/workspace. You may have all sorts of special pages to facilitate the workings of the portal and it makes more sense for them to be offshoots of a portal space than offshoots of a name: users will know what they are.

So I agree in principle with the portal namespace.

But how do we get round the objection that it will create a lot of work? Well, my suggestion is that it doesn't need to be fully switched. Every category doesn't need to be a portal because, as I said, a listing of every category can already be viewed. But if a portal is to be created, it needs to be done properly to avoid all the confusion mentioned above. The Wikinews:Portal proposal gave a good model that everyone can follow - I found it very usable. At the very least all portal pages must have:

• all name pages redirected to the portal so that you will definitely link to it when you link to, say, Burundi
• A DPL, along the lines of regions/topics if it is a big portal or just for all the stories on the category if it is a small, specialised portal.

Then there are other suggested templates created by UncleG which supply an input box etc for people just coming to that page.

This process is quite time consuming. However, Portals have now been created in this way for all the major regions and topics already, so that work has been done. I did it in that way for Burundi as a test and because I noticed there were increasing numbers of articles about that country and it worked fine.

I suggest that the way forward is that if people want to 'adopt' a category to become a portal, they should do so. Every category doesn't need to be 'done' and if it's going to be done, ensure all the redirects are in place so people get to the portal without needing to know they should type or search for portal:whatever. I will do this for the Quakers page today and if there are other categories people think are interesting enough to be promoted in their own right, people can do so as well. But it will be an addition, not a change so nobody will be forced to make major changes.

How does that sound? ClareWhite 10:04, 15 August 2005 (UTC)

Oh, OK, so the pages I thought were portals were put back. Let's get this thrashed out and then it will be easy to do what everyone wants ClareWhite 12:24, 15 August 2005 (UTC)

I think there needs to be a clear separation of Portals from Category pages. Portals would exist as a visual representation of the articles in category page. Category pages would simply list the articles in that category, as they do automatically. Category pages exist in their own namespace, Category:, so it makes sense for Portals to exist in their own namespace, Portal:. I'm glad we can move forward on this. -- NGerda 19:57, August 15, 2005 (UTC)

I support the change to the Portal: namespace, which is why I fixed double redirects for the Pennsylvania portal when NGerda made the change. If a user types in "PA" or "Pennsylvania", that user is redirected to Portal:Pennsylvania, so there is never any need to type "Portal:Pennsylvania" just to get to the portal - hence, I don't think there should be much confusion. Unless we come up with a better way to exclude Portals from article counts, etc, I think we should utilize the Portal: namespace. Also, who wrote all the unsigned comments above? It makes it very confusing to follow the conversation. - McCart42 (talk) 01:59:19, 2005-08-16 (UTC)

I believe the anon was Edbrown05. He told me he signed in, but the signature would only list his IP. -- NGerda 03:41, August 16, 2005 (UTC)

Dan100: Given that everyone seems happy to put in redirects so that all URLs point to Portal namespace where there is a portal, do you still object to the change? Does anyone else object? Is now the right time for a vote or are we nearing consensus? The reasons for seem pretty compelling to me ClareWhite 12:51, 16 August 2005 (UTC)

Yes, completely, because a) if redirects are put in place, what's the point in moving it, and b) if someone creates a new "Portal:whatever", I'd be extremely suprised if they knew to/could be bothered with creating a redirect for it. This screams my favourite phrase "solution looking for a problem". Why in goodness's name make something more complex just to get the total article count down by a few dozen. It's madness. Dan100 (Talk) 11:12, August 17, 2005 (UTC)

But it's not just moving pages, we're talking about creating projects with the portals, localism and all that. We've seen with the poor old Quakers how many extra pages you might want to create if you're going to encourage people to write about a particular specialism. Even if you don't do all that, a properly formatted portal page looks much better and is more likely to encourage contributors than a category page which shouldn't even be a page, because it's a category. So why not have portals in a namespace where it makes it clear it's part of a project and any extra pages can be neatly filed away? It does take work but that should be taken on by the person who wants to create the portal (it's the least commitment they'll need to make if they want to make something of it) and has already been done for the main pages before you reverted it (I'm not having a go, just saying if it is the will of the majority it can easily be changed back again) ClareWhite 11:26, 17 August 2005 (UTC)

New vote re-cap:

Suport = Eloquence ( easier article count, reduce dependency on DPL )

Suport = RossKoepke ( Maintenance, database, user-friendliness, future scalability )

Suport = NGerda ( localism )

Suport = Davodd ( localism )

Suport = Amgine ( database ease, current user friendly answerable with redirect )

Suport = Aphaia ( a watcher here, and I may be way wrong, but --> has similar proposal at Wikimedia )

Support = CmWhite ( 'topics' can be portals (( Quakers )), current system user friendly )

Support = McCart42 (underwrote redirects to Pennsylvania)

Support = Edbrown05 ( naming convention ugly and work intensive but if it matters it gets there. bureaucratic computer bullcrap demands naming conventions that makes fetching articles counts make sense, article counts in awareness statistics getting held up over this, we are losing awareness sensitivity by hooligans)

Oppose = UncleG ( never said so outright, but --> 'regions' can be portals, currently user friendly )

Oppose = Dan100 ( currently user friendly, mess to clean up after )

Oppose = Vask ( 'regions' and 'topics' are sufficient )

Abstain = Lief ( until it gets really local, then support at that level )

Abstain = IlyaHaykinson ( no purpose )

I hope nobody is misrepresented. And of course this is not meant to represent the final position of anybody on this issue. -Edbrown05 03:04, 23 August 2005 (UTC)

New vote re-cap:

Suport - Eloquence (easier article count, reduce dependency on DPL, architecturally necessary)

Suport - RossKoepke (maintenance, database, user-friendliness, future scalability)

Suport - NGerda (encourages localism, simple distinction between Categories and Portals)

Suport - Davodd (encourages localism)

Suport - Amgine (database ease, currently user friendly answerable with redirect)

Suport - Aphaia (a watcher here, and I may be way wrong, but --> has similar proposal at Wikimedia)

Support - CmWhite ('topics' can be portals (( Quakers )), Portal system user friendly)

Support - McCart42 (underwrote redirects to Pennsylvania)

Support - Edbrown05 (naming convention ugly and work intensive but if it matters it gets there. bureaucratic computer bullcrap demands naming conventions that makes fetching articles counts make sense, article counts in awareness statistics getting held up over this, we are losing awareness sensitivity by hooligans)

Oppose - Dan100 (currently user friendly, "mess to clean up after")

Oppose - Vask (no need for separate namespace)

Abstain - Lief (until it gets really local, then support at that level)

Abstain - IlyaHaykinson (wants more user-friendly name)

Abstain - UncleG (never said so outright, but uses category pages as portals)

I added to it it a bit to expand on user reasons and positions. -- NGerda 03:55, August 23, 2005 (UTC)

• I can't work out how people are associating putting "Portal:" in front of placenames somehow encourages localism. Just doesn't add up. Dan100 (Talk) 17:32, August 26, 2005 (UTC)

Besides that, perhaps someone could explain to me how this makes sense:

1. One reason for putting portals in the Portal: namespace is to have a separate article count. We often publish the overall number of articles. But this includes the ever growing number of portals and is therefore misleading.

Counting articles here is pointless, as that's not the goal. Plus the number of portal pages vs actual articles is miniscule.

1. It also affects the Special:Allpages display. If I can filter by namespace, I no longer have to view these pages when looking at articles.

Who does this, and why?

1. Fundamentally, namespaces have meaning. If we do violate that meaning, we're going to run into problems in other areas where it is interpreted. For example, if, using Wikidata, we attach a schema to the article namespace, so that we could have a "date" and a "sources" field. Then this would also be added to the portal pages. (Namespaces are linked to schemas in Wikidata.) There are also filters for Special:Recentchanges and User Contributions that work by namespace, and new filters like that will likely be added soon. So it's not a good idea from an architectural point of view to overload the semantics of a namespace.

How are semantics important?

1. It simplifies the process of creating portals, and filtering them from relevant lists, as there has to be no awareness of the category system. Just putting the page in the right namespace is sufficient.

I don't even understand what that means :-). Dan100 (Talk) 17:35, August 26, 2005 (UTC)

I asked Dan politely to abstain from reverting moves to the portal namespace, as now he is the only one opposed to it, but he refused. I am creating a poll to put this decision in the hands of the Wikinewsies themselves. Good day, NGerda 17:41, August 26, 2005 (UTC)

As we explained to you on IRC a while ago, wikis aren't democratic as everyone has equal powers. Consensus is the only way changes happen. Dan100 (Talk) 18:14, August 26, 2005 (UTC)

Which is why people, such as Ilya, are willing to support changes for the sake of moving Wikinews forward. It is unfortunate that we are moving no where. If there's one thing I've seen through all of this, it's users like Clare White who are saying, "Hey, can we move forward, instead of fighting?". I think we do need to move on. Dan, you won't have to do anything in terms of maintenance or page moving, and there are many who are willing to do it, so I'd hope you'd reconsider. All I'm asking for is that you not revert attempts to move pages into their namespace. -- NGerda 18:22, August 26, 2005 (UTC)

Move on by all means - by dropping this issue, and maybe even spending some of the time you spend arguing writing articles...

Anyway, following the arguments here is giving me a headache so I created Wikinews:Why "Portal:" is bad. I'd really like to see proponents of the system create and edit a Wikinews:Why "Portal:" is good page for comparison. Dan100 (Talk) 18:27, August 26, 2005 (UTC)

I still don't like the idea of using a separate name space for Portals. However, I really don't wan't to stop the progress (success) of Wikinews, so if everone else agrees I certainly don't want to stand the way (which means I lay down my vote if everyone else agrees). Väsk 19:19, 26 August 2005 (UTC)

I don't see how introducing Portal: will help anything, and it will cause some problems and extra work (not huge problems, but we can do without them for sure). Just leave it as it is. Topic instead of Portal:Topic. --Dčabrilo 19:22, 26 August 2005 (UTC)

I believe you mean Culture and entertainment, which would automatically redirect to Portal:Culture and entertainment. -- NGerda 19:24, August 26, 2005 (UTC)

Problem with version comparison

I don't know if it's just me, and if so I apologise, but lately the page where you can compare two version seems kinda screwed up. The links to navigate back and forth say "&larr Previous diff" and "Next diff &rarr" when I guess the "&rarr" should make an arrow appear. I have this problem with every Browser I've tried (FF, IE, Seamonkey) and don't encounter it on other Wikimedia projects. I've made a screenshot to illustrate in case nothing I've just said made any sense. --Deprifry 17:26, August 16, 2005 (UTC)

I think I fixed it, I replaced "&rarr" and "&larr" with <- and -> Let me know if that works. --Cspurrier 17:36, 16 August 2005 (UTC)

Wow, that was quick. Yeah, seems to be alright now. Thanks. --Deprifry 17:39, August 16, 2005 (UTC)