Project:Current issues
 Archives |
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Hello ppl, i can't create the above manual (index) (php), but this page is required for interested users, though so that the pages that have to do with the code, are completely in German. Maybe the admins here can change the filter, to remove the protection of page creation, namely, gets the following message when trying:
You do not have permission to create pages, for the following reason:
The title "Manual:Ind[..].php/de" has been banned from creation. It matches the following blacklist entry: (here appears a blacklist entry, but it was filtered too)
Hello, I want to get a "print"-link in the footer.
I know how to get a Link into the footer, but the following link doesn't work: [[index.php?title={{FULLPAGENAME}}&printable=yes|Druckansicht]]
How can I get this?
Paul
What if you use [[{{FULLPAGENAME}}?printable=yes|Druckansicht]]?
Media Wiki offers me to create a new page like "Pagename&printable=yes". The URL of the new site is "www.../Pagename%26printable%3Dyes".
I think the "&" and "=" has to be masked. But how?
Paul
Try the external link format like [{{SERVER}}{{SCRIPTPATH}}/index.php?title={{FULLPAGENAME}}&printable=yes Druckansicht]
The problem is: there is an underscore/blank in the pagename (e.g.: "Current_issues"). The external link will be cut at this blank.
Use [{{SERVER}}{{SCRIPTPATH}}/index.php?title={{FULLPAGENAMEE}}&printable=yes Druckansicht], then. Note the extra "E" in full page name. I just discovered this on Help:Magic_words.
We have tried more than once modified misinformation, but the editor always rejects amendments
You can compare page Arabic and English page
Attachment links:
English page: http://en.wikipedia.org/wiki/Al-Hilal_FC
Arabic page: http://ar.wikipedia.org/wiki/%D9%86%D8%A7%D8%AF%D9%8A_%D8%A7%D9%84%D9%87%D9%84%D8%A7%D9%84_%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A The article shows the sincerity of English I hope the support
Thank you & regards ,,,
when i download file with russian symbols (привет.jpg) i got Upload error
This wiki does not support filenames with special characters
mediawiki 1.21.1
iss8
mysql 5.6.13.1
php 5.3.27
This is a problem with MediaWiki on Windows. See this bug.
When I was here the last time, it was easy to find the correct version of an extension for my mediawikiversion - which is 1.17.0 - as than subversion was used to download snapshots. Now it is almost impossible to find the correct version as GIT ist used and only the newest snapshot is easyly found, while the correct old versions are almost impossible to identify.
Now I need Extension:ConfirmEdit to block spam and the newest snapshot doesn't work and I don't know if this is because it is not the correct version.
Yes, there's currently no way to reliably download extensions. This is very unsatisfactory and has been discussed several times on this wiki, bugzilla, wikitech-l and mediawiki-l but there's no solution on sight coming from the devs; try reading/joining those discussions to find partial solutions...
Additionally, 1.17 is unsupported and 1.18 will be soon the next, so I think you're really supposed to upgrade to 1.19 or 1.20.
The Review of extension pages takes too long to my mind. Especially if extension maintainer want to publish important updates on their extensions it might be a problem. For example the last checked revision of Extension:Math is dated back to June, 5'th;-)
You're right. These sort of issues (the RFC review queue is another example) are addressed semi-sporadically.
I suggest you post your concerns to wikitech-l so more people will be aware of them.
If you are knowledgeable about the extension, just ask editor flag. I would uncheck the whole page so that approval is no longer needed but I don't know how.
An editor flag would solve the problem for math. I was using RFC instead of wikitech-l, because I wanted to know if others have made the same experiences (maybe with other extensions) as well.
I'm trying to install: Extension:IIS REMOTE USER AD-LDAP
in the auth_remoteuser_iis.php, line 25, require_once('AuthPlugin.php'); What plugin is this?
If you know a better extension i can use to AD authenticate using iis please let me know.
Thanks!
Check out LDAP_Authentication, which is better supported.
The full-text grep search that gitweb used to have is now gone in gitblit: [1]. There is a "search" within each repo, but it seems to only search commit messages. Can we please have full-text search back?
I've investigated this a bit some days ago and now filed bugzilla:49674; it's not that simple, sadly. You can now use the Wikimedia technical search for simple searches, though.
The code editor gadget is broken:
Failed to load resource: the server responded with a status of 403 (Forbidden) https://toolserver.org/~brion/extensions/CodeEditor/modules/ace/ace.js?_=1371718573156
Can it be removed, since we have the same via CodeEditor extension? Though the extension is not enabled for CSS or JS, perhaps we should ask it to be enabled there?
Where do pages for new maintenance scripts go?
I just wrote Manual:SKcreateandPromote.php. Is this in the right namespace? Is it supposed to go where it is?
It would be better to use your commit access to submit patches to the original createAndPromote.php script.
Oversight and sysadmin aren't defined by core. Instead we should probably add some sort of --group or --groups param that'll let us add any number of arbitrary groups to the user. Either using --group=oversight --group=steward or if that's not possible something like --groups=oversight,steward or --groups="oversight steward".
I would just submit it to the regular maintenance script, were it for the fact that those user groups don't exist in the MediaWiki core settings. I would recommend a default Oversight group though, possibly a sysadmin group, but not all wikis need a group higher than bureaucrat. The only wikis I find it useful for are ones where the website owners aren't necessarily the main admins. In such cases, it's useful to have a higher group in place in the event that someone gives bureaucrat access to someone who shouldn't have had it. I might submit a change for defaultsettings.php that includes an oversight group. Because of the issue, I'll work on a script that can add a user defined user group, rather than a predefined one.
It seems that I'm not able to commit there.
If you can come up with a patch that implements this more generically (per Daniel's suggestion), I'm happy to commit it for you and provide you with authorship attribution.
The pages of about 50 extension which were tagged with security issues were just deleted. I think this is quite a drastic step since extensions providing according features must now we completely rewritten from the start rather than being fixed. Also deleting is the "wiki way of last resort" which is not justified in this circumstance. I think archiving extensions is preferable. Thoughts? PS I am not opposing to move these extensions out of business.
There was 37 deleted and tagged today, which now makes 58 removed in total.
This has been discussed previously (mostly on IRC) and we choose this option because we really don't want insecure extensions being used, and un-deletion is cheap (where as archiving them allows people still to get at the code in most cases). The lists of the current batches was posted to multiple IRC channels before hand as well.
"according features must now we completely rewritten from the start rather than being fixed"
These were all tagged for over 12 months. If someone cared about them, they could have fixed extensions or If this actually motives them anyone with rights can easily undo the deletion.
Here is the list of the pages deleted from this batch: User:Peachey88/Sandbox/SecExt, Did you know the oldest one was from March 2007?
The first batch of deletions appears to have been "03 April 2012" so it should be a few days before that.
Undeletion is cheap if people are aware of deletion and its reason. :) It would be nice to leave a redirect or a link in the deletion logs to a discussion or summary so that people know about it. Next time, it might just be a note in a deletion requests page or whatever.
We've been using the translate extension for a while now on this wiki, which definitely needs more multilingual support, so I think we should greatly expand its usage, by deciding where to start. The aim is to reach more MediaWiki users (rather than developers); benefits have to be balanced by costs, and in some areas the extension is easier to use than in others (or even easier than continuing with {{Languages}} and so on). Some ideas:
- Most viewed pages: I've done some, but they often need an update/revamp in English too.
- Configuration variables: hundreds of them have the corresponding Manual: page translated and can be assumed of interest. The pages use a common pattern and most important info is in the template, so – in principle – translations can be moved to the new system (semi)automatically.
- Help pages would be the most useful in theory, but those we have here are very specific and limited. It makes no sense to translate most of them, because the "real help pages" and their translations are in fact on Meta or scattered among Wikipedias (or other Wikimedia projects.
About #3: What about the users of non-WMF wikis? Wouldn't translated help pages be helpful for them?
Yes but one should first move the up-to-date and complete English pages here from Meta and other wikis (finding a solution for licensing problems and also convincing them not to keep outdated copies around), which is not going to happen.
You may be right. I think it was a mistake to insist on public domain Help pages, and that we are reaping the harmful consequences of that decision. But to fix it would require acknowledging that a mistake was made, and sometimes people are resistant to that.
I disagree - PD help pages are a very good idea. However, it is a mistake to think they will be of any real use until we provide a workable method of distibuting them. I think it is a fairly safe assumption that if there was an easy way to import the default help pages into your local wiki, in the appropriate language(s), then that would be sufficient encouragement for the current pages to be tidied up (if, indeed, that is necessary - I haven't looked at them for a while) and, more importantly, widely translated.
I don't think think the solution here is to import existing non-English help content from elsewhere, or to try and encourage a translation drive for the help content, without having an export process in place.
Configuration settings summaries have over 23 thousands translations for the Configure extension; it would be nice to find a way to use them on wiki. I've opened bugzilla:43380 to see what's technically feasible.
I'm not familiar with the Translate extension, although I'm looking for an excuse to finally give it a try. :) Is it possible to promote a set of pages where translation is prioritized? Using a category, for instance.
Trying to translate the whole mediawiki.org is pointless and actually counterproductive, but there is a bunch of pages that would really welcome more translations, and a formal request to be translated. It would be useful for the project and for translator to identify those, and if possible get those nice stats telling that Japanese is 100% up to date, Italian is 83%, Arabic is 12% and so on.
There are two types of translatable pages based on motivation:
- Promotion: local languages are good to reach out to new users and contributors. Homepage, the hubs, How to contribute, the local Groups (mainly in their respective native languages)...
- Support: essential pages for users of MediaWiki and our technical infrastructure. The most basic and required pages of the manual, how bugzilla works how to get developer access...
Maybe it's worth having both translatable categories separate? Maybe some languages make total sense for Promotion but less so for Support (no specific examples, although I can imagine Indic or Latin languages speakers needing those translations more for Promotion than Support, since the average sysadmin / developer of those languages is used to deal with English documentation).
It is clear that the deeper you get into both categories the clearer is the need to manage some English, at least in our current reality. We could probably define a VERY LIMITED set of pages translatable here and now in both categories and then consider the addition of new pages based on actual need.
And I agree with Nemo that those pages need a review in the canonical English version before making big calls for translation. But maybe this is a feature? It forces us to go through identified pages, mark them as translatable progressively and giving more time to translators to deal with new content. For instance, we could start focusing in How to contribute and Help:Formatting, and do a first test with these pages.
Yes, it's possible to "categorize" requests for translations, see for instance m:Special:AggregateGroups. It's also possible to define priority languages and even to disable translations in some languages, but this makes little sense on this wiki. In general, people will always translate what they're interested in, not what you'd most like to have translated, therefore if something would use translations it should be translatable, while for focused translation recruitement you can have a specific priority group of translatable pages.
In short, I don't like that "very limited" in all caps, unless you consider (like me) that e.g. 600 configuration settings pages (out of ten thousands content pages) would be a "very limited" set of translatable pages. ;-) Specific pages ready for translation should made translatable immediately: I'll comment on those two on talk.
Ok, got your point. I just find useful to have a set of pages identified for volunteer translators without own itch or agenda. "I want to start translating MediaWiki content to Catalan: where should I start? Thank you."
I've created a high priority group now.
http://stats.grok.se/www.w/top was updated; the Help: and Manual: pages in the top-1000 list should probably be made translatable. Who's willing to help me?
There are two extensions waiting for Git for quite some time now. It would be nice if somebody worked on it. Thank you and cheers
"This page is no longer being maintained, please request new repositories in the usual place. If wanting to import something from SVN, just leave a note in the comments."
If people were still waiting and cared, I'm sure they would go check the page and notice the message. Perhaps someone can let the users know on their talk pages that they should be re-filed at the new page.
If it is meant to keep a template from being printed, it doesn't appear to work.
Is there any coordination of people reviewing pending changes here on MediaWiki.org. I made a few changes which are still pending. Seems to be taking quite a while. But I'm not very familiar with Flagged Revisions. Maybe I just have to wait.
My changes were to Extension:NukeDPL and some related pages (see Special:Contributions/Harry_Wood) Maybe for extensions the expectation is that a maintainer of the extension would also be reviewing wiki changes? That's not going to work in this case, because it seems the extension itself isn't very well maintained
No, there is no coordination. Usually people just review stuff on their watchlist, I guess.
I appreciate that most people here know what they are looking for but a little sorting of the main menu (meaning what appears on the LH side of the screen under the logo) might just help occasional visitors. In particular the categories are not well enough sorted to mean that is much use as a menu item and the community portal just goes to the help pages (which are listed immediately underneath and would be found by anyone actually looking for that). Also on the main page there is an explanation of what mediawiki is (thanks, I have got that) but the relationship of this website to the software is a little unclear. Been like that for a long time I know... --BozMo (talk) 16:55, 3 September 2012 (UTC)
Good points and I agree.
I have started drafting the contents of a refreshed sidebar at User:Qgil/mediawiki.org_sidebar. Feedback welcome.
First page |
Previous page |
Next page |
Last page |
