Zapomněl jsem heslo a nevím co dělat dál
Zapomenute heslo ke hre
Logo is shown as text and not as a picture in navbar
i want to put a Logo into the navbar. I'm using the Tweeki skin. When i follow this guide, the text (
File:MYFILE.png)is shown in the bar and not the logo.
- Content of the 'brand' link. You can also use a image, e.g. set the content of the message to
File:MYFILE.png(without brackets) and costumize size and positioning for
(The site of the link is not mine)
Sysops can now add/remove the translation administrator group to self
Someone told me about this a couple of days ago, but I haven't seen it announced (well, not that I'm really subscribed to news mailing lists or whatever), so I find relevant to announce it here:
Bureaucrats on Wikimedia wikis where the Translate extension is installed can now add and remove the translation administrator permission by default. Administrators of wikis where this extension is enabled can add and remove this permission to or from themselves. Wikis that used a different configuration before have not changed.
This is going to be useful when there's a need to delete/rename a page marked for translation, and no translation admin is looking at this board, because admins by default aren't granted the translation administrator group by default.
See task T184610
Crud (create , read, update, delete)using external data
I need to create a page that will query external sql data and display the result on that page.
Also any user can edit the data and will automatically update the external sql database/.
Is there already such available extension ?
This page is for issues on MediaWiki.org website, not for support questions, please read the description of this board.
Also, MediaWiki is a documentation system, not a CRUD. There's no such extension, but if you have knowledge of PHP you may he able to come up with something to do that. A CRUD is something very specific (database, table, fields to update, layout, etc) that I would be surprised to find anything ready to use.
The Cargo extension could perhaps be what you're looking for. It can be used to query data in a database, and to write to it. I'm not sure how it goes doing both at once—you might have to first import your data into your wiki, if you want to be able to update it from the wiki.
Hi could someone please update Extension:ConfirmAccount because it last was updated with some new features when 1.20 was released and in 1.21 the longin and create account button was seperated and in ConfirmAccount it isent it is still together please update it with a new look. I have also ask on the mainteners talk page and they still have not replayed.
Well, this reflects the actual situation of that extension: nobody seems to be maintaining it at the moment.
Installation guide consolidation
Manual:Installation guide has one section with a 400 words summary, but then links to a "Main installation guide" composed of 4+4 more pages. None of these pages is translatable. Can we consolidate truly important information and make it translatable? Currently one is supposed to find the following logical steps.
- Download is the page
- Template:DownloadMediaWiki duplicates most info
- Download from Git is sometimes linked instead from docs
- Manual:Installing_MediaWiki#Download_MediaWiki_software duplicates it again
- Manual:Upgrading#Unpack_the_new_files again
- Manual:Installation requirements
- Manual:Installation guide has a largely duplicative summary (which I've now transcluded in the former). Does the complete page really offer any additional value to users (as opposed to devs)?
- Repeated in Manual:Upgrading#Check_requirements
- Actual preparation of requirements: Manual:Installing_MediaWiki#Create_a_database takes most of the space in the guide.
- The actual installation
- Misc troubleshooting and alternatives if something went wrong
- Manual:Configuring MediaWiki
or Manual:Configuration#Configuring MediaWiki (merge proposed)
- A handful of pages linked from there for specific config issues like Manual:Short URL and Manual:Page customizations
- More supposedly MediaWiki-specific server setup information, like Apache configuration, robots.txt, texvc, Comparison of extensions in distributions, ...
- Manual:Performance tuning
- Other stuff indexed in Manual:System administration and Manual:LocalSettings.php
- Manual:Configuring MediaWiki
- Informative material
The pages in bold are part of the official Template:InstallationNav (which complements Template:MediaWiki Introduction): they are supposed to be the official path and need special care and coordination.
Given Chad's comment, I'm also going to tag all "platform-specific" manual pages for merge to the main ones. Common parts can be merged and transcluded on the specific pages, while really platform-specific additional information can be left there. P.s.: for a start, I removed 5 guides on obsoleted systems and marked the others for merge.
Thank you for this!
- Manual:System administration could be useful if it becomes a reasonable index/step by step guide/tutoring of the really important pages in Category:MediaWiki for site admins (allowing to remove respective information from the general installation manual), but I'm not sure of its current role.
- Manual:LocalSettings.php is very visited, but it's quite a mess. I doubt it kept anywhere close up to date, is it currently making a good service to users?
I wonder what's the purpose of making Manual:LocalSettings.php translatable if you doubt about the usefulness of that page or if you plan/propose to improve/restructure it.
The page is vastly correct and the strings contained in it look rather stable, so it's ok to translate it. It is my impression that some consolidation will be needed for that page (reducing total amount of text around), but not a rewriting.
IMHO the direction is rather clear:
- always defer to other sites for guides on how to set up PHP etc.;
- keep all the steps internal to MediaWiki (like installer, config script, LocalSettings.php) in their own, shared manual pages;
- in all the setup-specific pages, just transclude the former and maintain only:
- information on packages available and how to use them (debatable, should be on their sites whenever possibles),
- OS-specific instructions which can't be found anywhere else, like specific paths to put in MediaWiki config or RAM/suhosin requirements and the like.
verify / review a page before publishing
is there a way to verify / review a page before publishing?
Step 1: a user is editing or creating a article, after finishing it is not published
Step 2: a user of a "reviewer-groupe" can confirm the change or new page -> published
The Newsletter extension is now enabled in MediaWiki.org
Ack & thanks for your efforts!
Hi, after a long long journey... Special:Newsletters!
Any newsletters within the scope of MediaWiki.org can be created. In previous discussions it was agreed to only allow administrators to create newsletters. Once a newsletter is created, their publishers can announce new issues at will without requiring administrators anymore.
If you want to create a newsletter and you need an administrator to do it, just reply here specifying:
- the name of the newsletter
- a short description, allowing this newsletter to be recognized in a list with all the newsletters
- a wiki page for its home
- at least one publisher (MediaWiki.org username)
If you want to report problems, request features, or get involved in the project, please check MediaWiki-extensions-Newsletter in Phabricator.
Hello. Congratulations, great job! As always, hewiki can help in finding rtl errors. And there always are rtl errors. So, we'd like to create a newsletter, meanwhile in mediawiki, and one day it will move to hewiki, when available. The notifications will be redirections to upcoming sections in he:project:news. So all notificatons will come from mediawiki to hewiki using Echo interwiki system, and will appear on rtl to subscribers. I created this news project, and publish about 80% of messages there for users, every time there is some interesting new mediawiki engine feature, for example. So naturally, I'll write the notifications. So, could you please create a new newsletter: 1. הפומפיה (the grater in hebrew) 2. עדכונים שוטפים על ידיעות חדשות בדף ויקיפדיה:חדשות (ongoing updates about new issues on wikipedia:news) 3. Sorry, what do you mean in home page? I should create something here in mediawiki? In which namespace? 4. User:IKhitron Thank you very much.
Hi @IKhitron, thank you for your interest. There is one problem: interwiki prefixes like he:project:news are not supported yet (see phab:T174664). I recommend you to wait until that is solved. Also, the idea of "migrating later to Hebrew Wikipedia" is not clear either (phab:T110645 is where we discuss interwiki / multiwiki support). Would it be an option for you to start testing in https://test.wikipedia.org/wiki/Special:Newsletters? I'm sorry for not having better answers currently.
Hello, Qgil-WMF. I think I did not explain myself well. I do not talk about an hewiki newsletter, but a mediawiki one. Local. It's issues will be wikilinks to hewiki in regular wikicode, that's all. There isn't something that doesn't allow to create it just now. And I did not talk about technical migration. One day when the extension will be deployed on other wikis, we'll ask the subscribers to subscribe once more, locally. So, could you do this now, please? Thank you very much.
N3 Thanks for phab link, I don't need it, because I don't need interwiki service, as I said.
> It's issues will be wikilinks to hewiki in regular wikicode
This is not supported now. The extension will not accept a syntax like "he:project:news". This is exactly what phab:T174664 is about.
Maybe I did not understand, Qgil-WMF. But I still think we are talking about different things. I'm not talking about interwiki link in notification - there will be regular mw:homepageofnewsletter#something link there. If somebody clicks and comes to this page, they'll find the interwikilink there, in the text (of the issue), on regular wikitext content model page. Thank you.
Alright, sorry, now I understand. The main page is required. It is where you explain what the newsletter is about so users can decide whether they are interested in subscribing, and any other details you want to add. Newsletter issues point to pages, and they don't take into account #sections. In wikitext pages sections are pure representational, and things are prone to go wrong if someone edits the sections (as opposed to renaming pages, which by default leaves redirects). A simple option would be to use Flow topics for new announcements, from the discussion page of the newsletter main page. Each Flow topic is a page indeed.
Thank you. Very well, Qgil-WMF. Looks good for me. So the main page could be the flow border, and subscribe button will be added to the description, or I need a wikitext page as the main one and flow page for issues?
You need a main wikitext page, otherwise you will not have a discussion page to refer to. :)
Great. So, I'll create a page and ask to convert its talk page to flow. So, it's the same question I asked at the beginning: In which namespace should I create the main page? I don't know this wiki structure. And "User" is not a good idea. Thank you very much.
A page in the main namespace is ok. You will get the Flow page automatically. There is no need to request anything.
Thank you for your kind recomendations. Done.
Could you, please, create a new newsletter:
- (the grater in hebrew)
- עדכונים שוטפים על ידיעות חדשות בדף ויקיפדיה:חדשות
- (ongoing updates about new issues on wikipedia:news)
Thank you very much.
Thank you very much.
Sorry for the time I spent you.
- I think you can make a summary of our conversation (flow, main namespace and much more) and put it on the project page, so these questions will not be asked every time.
- You thought I'm talking about interwiki newsletter at the beginning. I didn't. I didn't even think it's possible, otherwise you would not deploy this extension on any wiki, even here on mediawiki. Just once on meta, and it could be enough for all wikis.
- But all this made me find a bug in Flow: it does not work well on Timeless. So it's an adventage. :-)
Thank you again.
Congratulations to all those who made Newsletter possible. Looking forward testing and trying to better the extension. Regards.
Removing translation state from Manual:Configuration settings
Manual:Configuration Settings has been marked for translation when it shouldn't have been. Trying to remove it's translated state is not possible due to older-style translations (pre-Extension:Translate) that still exist as subpages. Attempting to delete the translatable page will also result in deleting those translations. Is there a way to remove the translation state without removing those older translations?
I have unmarked the page for translation and restored. /es, /pl, /ru and /zh should be restored (or merged) manually.
What is the reason "it shouldn't have been marked for translation". I don't see an obvious one.
I made a profile but didn't enter the temporary password in the week time-span. Is there anyway I can get another or something so that I can get an account?
You're looking for an account here?
I think you can use the password forgotton? feature on the log in page to get a new password like the first one. Now you've got a new password that you can enter in a new week time-span. And you needn't to wait because it's an autmaticly software feature