Project talk:PD help/Archive 1

Keep in the 'Help' Namespace?
Currently there's only 4 or 5 pages in this public domain manual. Before it gets any bigger maybe these pages should not be in the 'Help' namespace. Would it make more sense to put them in something like PDHelp:Contents? This would keep it seperate from the Help on using this website, or maybe there's no need to draw that distinction. What do you think?

Currently there's a Help:Technical reference page which is not part of the Public Domain Help Pages, but maybe that can be scrapped anyway. If we have pages which are PD, and pages which are not, within the Help namespace, I think we will get our knickers in a twist, because we need to avoid cross linking between the two, otherwise we are not facillitating easy copying of the texts.

I guess people might go to the normal help section of this website, looking for help pages to copy into their wiki, in which case the pages should be in this namespace. However the sidebar on the left doesn't take you to the normal Help:Contents. It is redirecting to meta.wikipedia.org so that's confusing. -- Harry Wood 11:12, 29 November 2005 (UTC)

This should definitely be in a new namespace since we are clashing with the non-Public Domain Help pages on this wiki. For example, I've recently expanded the public domain Help:Navigation page and found that it will be useful to have a page describing each of the special pages. However, Help:Special pages is already occupied by the non-Public Domain Help pages. The drawback to a different namespace is that it becomes difficult for people to cut and copy the pages since they will need to go through and edit each namespace reference in the copied text. I can think of two ways around this:
 * 1) place the public domain pages in a separate namespace but provide a mechanism that exports the pages for the user to download. This export should replace the PDHelp namespace with the Help namespace during the export. This would allow users to grab a snapshot of the pages to upload into their own wiki. The drawback is that it makes it harder to contribute to the public domain help pages.
 * 2) move the non-public domain help pages into a different namespace. This requires that the resources sidebar for the MediaWiki site be modified to reference the new namespace and all non-public domain pages to be moved into the new namespace. This approach means that editors of the non-public domain help pages need to work in the new namespace. The benefit is that the public domain pages are easy to copy and there is a lower barrier to contributions in the public domain pages.

Additionally, having a page that provides a complete list of public domain help pages (including templates) to facilitate copying of the pages to a new wiki would be useful. I've just spent a fair bit of time resolving template issues after copying the PD Help pages to my own wiki. The main issue was some confusion over the name of the highlight templates used in the prettytable template. Providing a list of pages that need to be copied over to get a full set of the current PD Help pages would alleviate this problem to a large extent. --Mrichmon 20:35, 10 January 2006 (UTC)

It seems that there are actually two types of help pages - one which is related to the wiki as a software package and the other which relates to the wiki as an installation. These public domain pages fit into the first category.

A different approach might be to write these pages as templates. Then the pages in the Help namespace could simply contain a reference to the template, so the help system could be completely customized in the Help namespace.

--Thierry Lach 15:55, 15 January 2006 (EDT)

Allowing copying is the whole point
When explaining why the pages are licenced as public domain, it's not enough just to say "This it to make it easy to use this manual". The manual would be 'easy to use' if it were GFDL, but it would not be easy for someone to copy the text into their fresh wiki installation, since they would have to attribute the work somehow. The same applies to the linking guidelines lower down. Allowing people to copy the text into a fresh wiki installation (or distributing with mediawiki) is the whole point of these pages. Let's not be vague about it.

Perhaps I'm assuming too much. That is the whole point right? People who just want to create a manual, and are not focussed on allowing people to copy it, can contribute to the centralised Documentation right? To clear up this confusion (if anyone is confused) we should maybe not have these pages in the 'help' namespace (see above). -- Harry Wood 11:56, 6 December 2005 (UTC)

Screenshot
We should not have screenshots in namespace "Help:". Screenshots are not necessary for the purpose of generic site user help. They would complicate the inclusion of en:public domain (PD) Help into MediaWiki distributions and would likely cause difficult licensing issues. Can MediaWiki screenshots be licensed PD? No. Can they be used in documentation for documentation purposes, yes. But we do not need them and we cannot license them PD. Simple is better. Please leave screenshots out of PD Help so that it remains a practical and maintainable set of PD generic user help documents and easily to included in MediaWiki distributions. Thanks you. --Rogerhc 22:56, 30 August 2006 (UTC)

Screenshots should not be put into namespace "Help:". The following has been moved to this Talk page for reference only:
 * Use http://test.leuksman.com/view/Main_Page for taking screenshots
 * Screenshots should be cut to show only the relevant part of the site (no browser surroundings).


 * This needs further discussion at Project:Current issues. --HappyDog 03:42, 4 September 2006 (UTC)

WOW - so let me get this...
... I am suppost to produce an entire help section from SCRATCH for my users?!?! that seems a bit wacked - if i may say so... besides, isn't the POINT of a wiki is to SHARE the usage manual for its product so that it is easier to use by EVERYONE hense INCREASING demand? (or am i missing the point again?) besides, observing the CC licencing means i need to give credit where credit is due... sooooo where is the author info? or am i missing something still? -- Dsgncr8or 08:06, 31 August 2006 (UTC)


 * The latter. --HappyDog 13:53, 9 December 2006 (UTC)

The licencing issue
It's specified PD because "This is necessary in order to allow people to easily copy the text into their own wiki installations.".

This isn't a problem as GFDL §7 states: "When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.".

Thus I suggest to scrap this "PD" experiment and go for GFDL instead. → Aza Toth 20:31, 8 December 2006 (UTC)


 * Hm? Maybe you didn't get the point. The above is well known. But this would mean that reusers have to mark all help pages from MediaWiki.org as GFDL content properly somehow (authors/source/history…), and, if you think e.g. about all these usual but weak&wonky "from Wikipedia" links, and that reusers are not allowed to remove such links (if at all pure linking can be regarded as sufficient), you might understand the broad request for "really free" help files.
 * Note: The common expectation is, that the default help pages will be adapted mercilessly to individual needs on other installations, and that they will be surrounded by and mixed up with other self-written help pages, so that it would be quite difficult to divide one (original/default) from another (self written) help page after some time.
 * The PD idea did not come up because we fear clashes between different licenses on third party installations or legal issues (to be honest - nobody really cares who the authors of such pages are) . It is mainly because we want this stuff – as a very principle goal – to be usable as easy as possible. We also know pretty well, that a relevant (in my opinion: huge) amount of MediaWiki users don't have a clue about proper licensing – they just use "free software" for their projects and consider help pages as an essential part of the software – and this group is relatively larger than the group of ignorant reusers of "creative" textual content (e.g. from Wikipedia), where more people understand the need for attribution, naturally.
 * So we will distribute a set of up-to-date fundamental help pages and allow easy use as is. The main practical aim is that the reusers can take these pages without having to ponder if and how they are allowed to do what, and without having to attribute any authors nor the document history and source (as it would be necessary under the GFDL) – just the pages as they are, without any limitations. This is unregarded of which licenses/copyright their "aggregate" has or will have.
 * ... ugh, written too much already ;-) -- :Bdk: 03:30, 9 December 2006 (UTC)

nonsense in help space
I just updated my help space, including Help:Aiai. So it may be sueful to think about a way of avoiding nonsense; this hung around for a month (so far) since it isn't connected, so it wouldn't be seen until a bot picks it up. But only grabbing pages linked from help:contents could miss some that are linked to from the mediawiki: NS (i.e. help:editing, which should be somewhat comprehensive) Well, something else to think about. -Steve Sanbeg 00:51, 15 December 2006 (UTC)


 * Maybe enforcing the licensce will work, the bot can skip any page that is missing the PD header; then those can checked, and either replaced or deleted. Maybe a new speedy category should be added? -Steve Sanbeg 17:13, 18 December 2006 (UTC)


 * There's not much we can do from this end, except keep an eye on special:recentchanges and special:allpages. I think it is probably a good idea for your bot to skip any page that doesn't have the PD notice on it - preferrably outputting a list of all those that were missing it so it could be added or the page deleted.
 * I don't think we need a new speedy template/cat. If it is nonsense then use speedy.  If it is in the wrong place move it and speedy the redirect.  If it is untagged, tag it. --HappyDog 19:40, 18 December 2006 (UTC)


 * OK. Skipping them would be nice, although this page only get deleted because I found it on my wiki.  Maybe adding a delete tag to non-PD help pages would help get rid of these. -Steve Sanbeg 01:16, 17 January 2007 (UTC)


 * As per my previous comment, non-PD pages should be moved out of the Help: namespace, untagged pages should have the 'PD help' tag added and junk/vandalism should be marked for speedy deletion. Don't automatically tag them, but get your script to output any pages without the notice and manually perform the appropriate action for each unmarked page on a case-by-case basis. --HappyDog 02:41, 17 January 2007 (UTC)

licensing templates
Currently each page in the help namespace has a header that puts the main content into public domain, and includes several template which are apparently GDFL. I suspect that this is an oversight; but it would really be better if all of the help content (main pages, templates, images) had a consistent license. -Steve Sanbeg 17:11, 18 December 2006 (UTC)


 * All help content will _need_ a consistent license, but until now only the help page content itself has been considered. I suggested that all help page templates that need to be part of the export should be located in the Help: namespace (not the ones that _don't_ need exporting, like the PD notice) and that cats & images have a standard prefix.  More thought about this is definitely required though.  It does throw up licensing issues... --HappyDog 19:44, 18 December 2006 (UTC)


 * Won't it become more difficult to relicense the templates later on? Do we need to contact all of the authors, or replace templates that aren't PD?  I'd think the sooner we can put a PD disclaimer on the template, thus making all subsequent edits PD, the simpler thigs will be.


 * On a related note, I'm still not sure about putting all the templates in the help namespace, as that would make help:templates pretty contrived. I'm not sure about a good solution to that, so I currently just grab any referenced templates, minus a list of known exceptions.  Maybe using a PD disclaimer on the templates to be copied, (and maybe some other disclaimer on the ones that shouldn't) and hopefully keep the ones that shouldn't  a minimal list (ideally one header & one footer) -Steve Sanbeg 20:03, 18 December 2006 (UTC)

Installation ram requirements
I am starting to install mediawiki on php 5.1.5. A warning message comes up to say that I only have 64m. I can find no place in the manual or requirements that states what the ram requirements are. My hosting company says 64m is generous and 8m is defaul for php5.1.5. So how much php ram do I need?

Larry


 * The warning will always come up, no matter how much memory you allow PHP to use. It's a generic warning. 64m should be enough. -- Duesentrieb ⇌ 10:21, 25 February 2007 (UTC)

Missing escape clause?
I noticed this in the box below the edit window Contributions to all other pages are considered to be released under the GNU Free Documentation License.

Shouldn't there be some kind of escape clause to explicitly release pages to PD? It seems that even if every page in the PD help project were to state that it was PD, the PD help would still be GFDL, since that bit would still apply to the templates & images. Maybe we should change it to:

Contributions to all other pages are considered to be released under the GNU Free Documentation License, unless explicitly released to the public domain.

-Steve Sanbeg 00:54, 17 January 2007 (UTC)


 * The big problem is one of clarity. The whole idea with the help namespace (i.e. a separate namespace, a thick blue border, the watermark, the PD notice) is to make it completely clear to contributors that anything they add will be released as public domain.  As soon as we start having clauses (GFDL unless the page says 'PD') then we get into trouble.  What if someone makes an edit and removes the PD tag? What if several other edits happen in this state?  I can easily see a situation where someone complains that the content they released as GFDL is being distributed as PD - maybe because they didn't understand our licensing or maybe due to prior/subsequent edits.
 * I don't really have any decent solution, I'm afraid, but I think the situation is more complicated than simply adding a tag to random pages that should be PD.
 * Can we make a list of non-help-namespace pages that we need to include. I suspect we can work round the limitations for everything except the images (which are of dubious licensing anyway, as they are screen shots).  E.g. is it only the template that is used in the examples that needs to be in the template namespace?  If we keep this simple enough it will probably be beyond licensing anyway, e.g. if it just says "This is an example template", there is no way that any-one can copyright or restrict it's usage as it is so commonplace.
 * --HappyDog 02:34, 17 January 2007 (UTC)


 * Seems reasonable. Of the templates, thankyou would have to be in template space; prettytable, Hl2, Hl3 and meta are also used elsewhere, but I guess could be forked.  Admin_tip is mostly used here.
 * I think the images themselves are PD (we changed all the examples to Example.jpg because of that). I assume that GFDL clause only applies to the image descriptions, not the images. -Steve Sanbeg 16:07, 17 January 2007 (UTC)


 * From that list, only Template:thankyou (as an example of using templates) needs to be in the template namespace - all the rest (as functional tools in laying out the help pages) can be transcluded from the help namespace instead. To stop unwanted forking, the Template namespace versions that are to be used on the rest of the site can simply transclude by using e.g.  (passing on any arguments, if necessary).  That way we have a single 'non-PD' template, and that template is so minimal as to be unlicensable anyway.  If the current version of thankyou doesn't fit that description then we need to modify it so it does.
 * Images licences are marked individually on the appropriate image page, so you're right, PD images can happily be stored in the Image namespace as long as they are appropriately marked. Images used in the help documentation should all be PD - ideally any script will report and ignore any images that do not have the PD tag.  We have a BIG issue that needs clarification - what is the legal status of MW screenshots?  I might ask on the mailing list, because currently they are tagged in various ways and we would obviously like them to be PD.
 * Image pages are currently GFDL. We will need a way to ensure these are PD - perhaps we don't include the image description in the import?  Or replace it with a standard "This is a PD image used by the MediaWiki help pages" notice, and ignore whatever is on the page.  Other suggestions welcome.
 * --HappyDog 23:48, 17 January 2007 (UTC)

use of Manual: internal link
As the interwiki link Manual: isn't a default link on installation but is, should links like Manual:blah be replaced by mw:Manual:blah ? - Foxhill 03:24, 25 February 2007 (UTC)


 * Manual isn't an interwiki prefix, but a namespace here on mediawiki.org. If you want to link any page on mediawiki.org from your wiki, you have to use the prefix mw: flus the page name, inlcuding the namespace name. So, you would use Subversion, mw:Manual:database_layout, mw:Help:links, mw:Extensions:Makebot, etc. I'm not sure what you mean be replacing Manual:blah by mw:Manual:blah ... where, when, why? -- Duesentrieb ⇌ 10:18, 25 February 2007 (UTC)


 * I mean on the PD help pages such as Help:Images and Help:Interwiki linking, I apologise if this wasn't clear. I feel it would be easier to use Interwiki Links that would work by default so that when someone copies the Help pages onto their own wiki they would work without having to edit the database to add new strings. Just thinking of ways to make it easier, and of course with using the default Interwiki's, any future export procedure can be simplified as you won't have to do any link conversions. - Foxhill 18:31, 25 February 2007 (UTC)


 * If you are sure that 'mw' interwiki is available by default on new installs then this seems like a sensible idea. --HappyDog 16:11, 23 March 2007 (UTC)


 * Oops - looks like I edited an old version of the page by accident! Here's the comment I deleted:


 * Hrmm, nevermind it seems. For some really bizarre reason or any other interwiki to mediawiki.org isn't a default link either. - Foxhill 13:47, 1 March 2007 (UTC)


 * ...so it looks like it's not possible. Ah well. :) --HappyDog 23:28, 26 March 2007 (UTC)
 * It looks like you spoke a few days too soon; mediawikiwiki: was added 3/29. -Steve Sanbeg 20:55, 7 June 2007 (UTC)

Simplified or Traditional?
The only two Chinese pages (Help:Contents/zh, Help:Tables/zh)in the PD help pages are written in Traditional Chinese. Thanks. --Kakurady 07:49, 1 July 2007 (UTC)
 * Is there a policy for this?
 * Can I add a page, translated into Simplified Chinese, to them? (I agree to release it into PD.)


 * I have virtually no knowledge of the various Chinese dialects. Please take a look at the current list of languages at Template:Languages (scroll down to the table - the language codes are in bold) and let me know which language code should be used for the current content (zh/yue/zh-hant/etc.) and I will move the pages to the appropriate location (or perhaps you can - I don't know whether non-admins can do that or not).  Once they have been moved then I would welcome your contributions in simplified Chinese (or any other supported language/dialect, for that matter) - just create the page using the appropriate code.  Let me know if you need any help with any of this - it is not completely straightforward, and may appear a little daunting at first! --HappyDog 01:56, 18 July 2007 (UTC)


 * I only have a little knowledge of the dialects & scripts, but I suspect that we don't need seperate codes. They should be fairly interchangeable, since one is just a more accesable version of the other.  I think anyone that knows traditional could also use simplified, and most people who know simplified could also read traditional.  Since there's no policy on it, it should be fine to start adding Chinese pages.  Personally, I'd think simplified would be preferred, since (I think) more people can write it, although I'm certainly not an expert. -Steve Sanbeg 15:48, 19 July 2007 (UTC)


 * According to Project:Main page templates there are currently at least 4 Chinese dialects that have some representation on this site. I have no knowledge or authority on this matter so I don't know whether that is appropriate or not, however as long as the correct language codes are used and the Language policy is followed then I have no problem with content being added in any language. --HappyDog 00:28, 20 July 2007 (UTC)


 * If I understand correctly, the question wasn't about dialects, but about scripts. It looks like the main page currently has 4 codes -- zh-hans (simplified script) zh-hant (traditional script) zh (unspecified script, but looks the same as zh-hans, so presumably simplified) and yue (cantonese (I guess the rest are Mandarin, unspecified script).  The policy does seem to somewhat contradict itself on this, since it says (in template:languages) not to add content in languages that don't have a wikipedia, while 3 of the 4 Chinese codes don't have corresponding wikipedias.  If these are as interchangeable as I think, then it would fragment the help pages too much to split two interchangeable scripts into 3 arbitrary codes.  I can see where the codes would be useful to useful for automated conversion, but may make the layout too confusing for people.  Kakurady, does this sound right and make sense?  Anyway, since zh is apparently already mixed, if you can't or don't want to write in traditional, it should be fine to write simplified.  We may even want to merge some of the codes to make the policy more consistant, and the docs easier to find. -Steve Sanbeg 15:28, 20 July 2007 (UTC)


 * Please see User talk:Shinjiman for some previous discussion I had with the user who created these language codes on this wiki. The language policy is correct, and if we there are pages (as you highlight) that don't follow the policy then they should be merged/renamed/deleted as appropriate.  I don't think I have the knowledge to do this myself though. --HappyDog 19:14, 22 July 2007 (UTC)