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)


 * The above was an old discussion. I think it's largely resolved now, in that everything in the Help namespace is very clearly labelled as Public Domain. -- Harry Wood 15:15, 7 November 2007 (UTC)

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)


 * It is "a bit wacked" that MediaWiki doesn't come with some built in help. That's what we collectively here are trying to resolve. In the meantime you do indeed need to produce an entire help section from scratch for your users.
 * In the past most people setting up a wiki, have simply linked to wikipedia's help, or copied a page or two from there (and hopefully linked & attributed appropriately) These are not very tidy solutions. What could be a concise simple set of help pages, ends up being a rabbit warren of complex structures fragmented across different websites, containing irrelevant cruft.
 * Public domain help pages are the way forward. So you've found the right place! Unfortuntely they're not quite finished yet. -- Harry Wood 15:26, 7 November 2007 (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)

templates naming
I have create the PD help template like, Template:Help/Categories. Should I rather use the name like Help:Template:Categories for PD help templates? --Ans 14:16, 10 June 2008 (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)


 * "zh" is a code for "generic" Chinese, i.e. neither simplified nor traditional. It may have manifested as "zh-cn" due to personal locale settings. Most of articles in Wikipedia is written in vernacular Chinese which is neutral to the writing script, therefore the Chinese Wikipedia uses an automatic conversion system. In any case, the opposite script is just a Google Translate away. --Kakurady 02:00, 9 November 2007 (UTC)

Huh, somebody's converting my translations in simplified script into traditional script. --Kakurady 20:34, 19 December 2007 (UTC)

Code for PD help pages
Hi, I am wondering where I might be able to get hold of the code that enables the PD pages and maybe a bit of documentation on it. Kindly let me know. Stephen Ewen 04:02, 19 October 2007 (UTC)


 * peblusto asks: ... other than clicking [edit] behind any PD public domain page you want to copy/study? what exactly are you looking for? what do you think is happening special for "PD" pages to "enable" them that is different from all other pages? how can we help? i'm looking at:
 * Project:Help
 * Category:Help
 * Project:PD_Help
 * Project:PD help/export
 * Project:PD help/mirroring
 * ...now, there's a Special:Allpages/Project: namespace whith "PD..." entries and a Special:Allpages/Help: namespace with no "PD..." entries, but many of us want to copy or refer to the help pages here from our own wikis. is that what you are trying to do - to have pages and links in your own wiki refer to or link to or automatically bring information from the mediawiki.org "PD" public domain pages?  from Help:Links there's this example:
 * Interwiki link (code) MediaWiki = MediaWiki
 * ... which leads us to Help:Interwiki linking which offers:


 * Note: In some installations none of these is pre-installed. Try  in this case.


 * is that useful? i think "PD" public domain pages are just where contributors are forewarned that the page is intended to be public domain and should never contain anything with copyright restrictions, otherwise, they are no different from other wiki pages.


 * let us know how we can help. - peblusto 09:32, 19 October 2007 (UTC)

Hi Peblusto. Thanks for the info. What I most have in mind is the code that actually produces the visual change on the PD help pages, e.g., at Help:Editing_pages - the thick blue border and background image - which I think is a nicely eloquent solution you all came up with. Obviously, this is not something that is template driven only but is something I'd guess sysops can "switch on". It would be wonderful to have that ability at the CZ wiki for articles that began as WP articles, as our current method has meant users will once in a while inadvertently remove attribution, something we fix pretty rapidly but for obvious reasons wish to be 100% perfect on. Of course, there would be some redesign to tailor the background image to be GFDL and as from WP. I'd appreciate very much any help about knowing how you all implemented the PD help page design. Stephen Ewen 06:15, 7 November 2007 (UTC)

'Target readership' section - sysop functions
I added the "target readership" section. Do people agree that the Help pages should not go into too much detail about sysop functions, or at least should give less emphasis to these subjects?

I think the current Help:Range blocks seems particurly out of place, although I guess it might be OK if it were tucked away somewhere without being linked from Help:Contents -- Harry Wood 15:13, 7 November 2007 (UTC)


 * I think we want to keep things like that in the help space. When you install your new wiki and find a page about IP range blocks it would be useful to have help about that feature readily to hand (especially if installing on an VPN or other non-web-enabled system).  I think that we should probably have a 'Administrator Tools' link in the main index, and tuck advanced features such as this into sub-pages of that. --HappyDog 07:55, 8 November 2007 (UTC)


 * Yeah that's a good idea. A seperate contents page listing the Help pages directed at sysops & bearocrats. This will keep the front page Help:Contents looking nice and concise. -- Harry Wood 10:45, 8 November 2007 (UTC)


 * I generally think it's best to keep the help simple for users, since this is meant for local admins to copy for their users. Although it is useful for them to have some overview of privileged operations, too much would be confusing.  Installation tips should be wrapped in the admin_tip template, so a local wiki can blank that template to excise these. -Steve Sanbeg 23:46, 26 November 2007 (UTC)


 * I'd like to draw a clear distinction though, between server administration configuration information, and sysops/bearocrats feature documentation.
 * The admin_tip template (very brief little boxes) is for server administration tips, which may be useful in places, but in my opinion should be kept to a minimum.
 * Meanwhile Sysops/bearocrats features are available just with a different permissions level within the MediaWiki software (no server tinkering involved). We're saying these features should be documented as part of the Help package, but just tucked away in a less prominent place.
 * -- Harry Wood 12:33, 27 November 2007 (UTC)

Flagged revisions
We should have a policy in place to suppress vandalism from these pages, so users can easily copy/mirror a good version. The need for this has been known for a long time, but we couldn't have a detailed discussion about it until the software caught up. Now, we should figure out the best way to implement this; i.e. what flags are available, who can add them, what versions are normally displayed, how to access the flagged revisions, etc. -Steve Sanbeg 19:54, 8 August 2008 (UTC)

The footer
Well, with the help of parser functions, check out what we did to the bottom. ViperSnake151 22:41, 3 June 2009 (UTC)

Are there version specific PD Help Pages ???

 * I have Mediawiki 1.11.2
 * I Imported the help pages as prescribed, but on the first help page it wants to display a .svg file which I can't even upload to my MediaWiki - it does not support this image type.

Plus, I expect the help pages to differ release over release so what do I do to get the right help pages?

Thanks


 * Unfortunately, the help pages generally only document the current features of MediaWiki. Some of the more-developed pages tend to indicate which version various features were introduced, which may be helpful.  The main changes that will affect the help docs are likely to be additional Magic words and parser functions, the change in the preprocessor which altered how complicated templates are expanded, and tweaks to the image link syntax.  Happy ‑ melon 09:46, 11 July 2009 (UTC)

"int:" vs "MediaWiki:" prefix for messages in PD Help texts
Dear Colleagues! Do I understand correctly the appointment of "int" prefixes using, or they need to be replaced by localized messages according to translation language? Or need to be right this way (see difference comment)? --Kaganer 21:24, 1 May 2010 (UTC)
 * I would prefer that the content is always in the same language, either by hardcoding the string or using "MediaWiki:". Also one problem with "int:" is that it'll be in English for anonymous users (on this site), even on translated pages.  i Alex  15:06, 9 May 2010 (UTC)
 * Why is this a problem? Using "int" guarantees that the user will see in the help interface elements exactly as he sees them on screen - regardless of whether the help text in which language he reads. For anonymous users it is as true as it is for the registered... Not? --Kaganer 01:18, 11 May 2010 (UTC)
 * Both methods have their advantages and disadvantages. The question is which one we choose? Before 1 May, I thought that the first (with "int:"). --Kaganer 01:23, 11 May 2010 (UTC)

Consistency regarding use of the Admin tip template
This page states:
 * Admin tips: If something in Help can be configured by a server administrator, you can insert an admin tip with.

Yet, the tips have been removed from the Help pages (example) with the justification:
 * Removing admin tip template from NS_HELP. This is a PD namespace and that template doesn't belong. The help namespace also needs to be as self-contained as possible or we'll never ship it with MW.

Do we correct this page or put the templates back in? Hamilton Abreu 18:36, 21 May 2010 (UTC)
 * I think we should correct the page. In general, we need to keep the help namespace as free from external requirements as possible. This will make it easier to (one day) package it in default Mediawiki. Adding templates and such makes that more difficult. Not to mention the issue of it being outside the Help namespace, and thus not PD. ^demon 18:47, 21 May 2010 (UTC)