Project:Current issues
 Archives |
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Template:Extension/de not accepting translations
I just translated stable for Extension:ConfirmAccount/de and now it's saying that it's an unknown status.
I would like to have a category with all /status pages so that we can use Special:RelatedChanges to get a RSS feed similar to this, but for status updates.
What do you think about it?
Makes sense. You'll have to check that the JavaScript helper to add updates, LST and maybe something else don't break in some way, though.
I think there will be no problem with the script if we insert the category tag between the "Last update on" line and the first heading of the status pages.
What would be a good name for it? Category:Status pages?
Fine, unless you like Category:Project status better. (only a suggestion for a more explicit name, not willing to bike-shed) :)
Category:Project status seems better. I'will use this. :-)
PS: The changes can be seen at Special:RecentChangesLinked/Category:Project status and the associated RSS feed.
Grammatik prüfen für Extension:ConfirmAccount/de
Kann jemand dieser Artikel prüfen?
Although we have several templates (and parameters in templates) to mark the status of extensions, functions, and variables (e.g., obsolete ones), we don't seem to have similar templates for releases of MW itself (i.e., something that can be slapped on a page like MediaWiki 1.18 to quickly and clearly explain that it's an old version that shouldn't be used, etc. — somewhat like {{oldupgradenotes}} except not for pages about upgrades). I'm thinking {{MW release status|ancient}}, {{MW release status|legacy}}, {{MW release status|lts}}, {{MW release status|stable}}, etc? (Whatever the proper set of terms would be...) Would such a template be worth making?
I think there is a benefit, so if you want to, go ahead and make it.
Since I'm not too familiar with the subject matter (i.e., MW as a piece of software), I was hoping someone else would want to do it...
If you can create the initial templates, then I can apply them.
The formatting of Template:MediaWiki News seems quite awkward to me, with bullet points on the dates but not on the (indented) items following the dates. I think this should be the other way 'round. Interested parties please see my comment at Template talk:MediaWiki News#Formatting and reply there, if necessary. (I would have just used {{editprotected}} on the talk page instead of posting here, but I couldn't find such a template here on this wiki.)
Dropping here:
Nikerabbit> an idea from the xwiki presentation: make one search for docs, bugs, irc and mailing list
(from FOSDEM). Done as [1], maybe it's useful for some. Google is the only option because we don't have any mailing list search (even with Google we have to rely on a mirror).
As requested by Waldir, I've placed the list of URL on User:Nemo bis/MediaWiki search for everyone to edit. Let me know if you are interested in being added as administrator.
If people like it, it's extremely easy to integrate it in the standard MediaWiki search, see for instance w:it:Speciale:Ricerca.
What do you mean? It's a sysop action (adding some JS to MediaWiki:Common.js), so this is the place where to discuss it.
Hey folks,
E3 deployed Extension:PostEdit and Extension:GuidedTour here on mediawiki wiki today. This is partially because they are dependent on each other, and we want to allow volunteer developers bulding tours to test things out here.
If you want to see how GuidedTour works in a general sort of way, you can force a tour by adding ?tour=test to any URL here. If you've edited in the last six month on most of the top ten Wikipedias, you'll already know what PostEdit looks like. If it bugs you and you want to hide it, add the following snippet to your personal CSS:
.postedit { display: none; }
P.S. Apologies if this is the wrong spot to announce.
Have you announced this anywhere else? Is there a wiki page explaining / discussing the implementation of Guided Tour in mediawiki.org and what could we do with it in order to e.g. help new users and contributors?
There is documentation at the guided tour extension page linked above, and at guided tours. I previously announced this on the local wikis where it was added, and we've held IRC office hours about making tours.
See Category:Top level, as example. With trying clicking to [+] button near any subcategories, returned error message "categorytree-collapse-bullet: Parse error at position 0 in input: "
Is it appropriate to import w:id:Bantuan:Pywikipediabot to Manual:Pywikipediabot/id ?
Some pages that are currently fully protected could benefit from a less rigid protection scheme using Flagged Revisions, allowing more editors to suggest edits without risking having highly visible pages contain potential gibberish. I propose changing the fully protected pages to Flagged Revision's "Require review for revisions from everyone except Reviewers" setting. That way people can suggest edits but these won't be publicly visible unless approved by a reviewer or administrator. Optionally, semi-protection can be added to prevent edits from unregistered or new accounts. What do you guys think?
The principle sounds interesting. What pages are you thinking of? Maybe it's easier to just report pages that should benefit from Flagged Revisions and change their status unless there is a good reason not to. Should we try with a just a few first?
There are 7 in ns0 (none worth unprotecting), one in Extension and none in Help or Manual. Waldir, what pages are you talking about?
I'm thinking all of them, really. It might be worth revisiting what we understand by "worth unprotecting". There is always a small detail (a typo, a minor rephrasing to make things clearer, etc.) that we will overlook — nothing's ever perfect, after all. As an example, just yesterday I noticed that the main page has a link to "How does MediaWiki work?", a redirect that can be replaced with its actual target, "Manual:What is MediaWiki?". Requiring edit requests makes the workload for such small edits triple. Besides, this wiki doesn't get much vandalism/spam (AFAIK), so it shouldn't be such a problem.
In any case, we can certainly try it with one or two pages and reassess after a month or two. Any edits will only be visible immediately if made by reviewers or admins, and should any of them screw up (which is rather unlikely to happen, as you might imagine), the right can easily be removed; at the same time, autoconfirmed users will be empowered to suggest edits (to make a git analogy, that's kind of a pull request rather than a patch, where the final repository gets the actual authorship in the version history). So what do you say about a test trive?
It's no big deal. If it's just those 7 pages (I'm excuding the main page and Visual editor/Feedback which might still be linked in edit view from somewhere) I can do it immediately.
I follow the versionning of Scribunto. The new version of Mediawiki installed yesterday do not show Installed extensions versions. This happened also for some others Mediawiki versions but not successive.
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.
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.
Heiya, I would like to suggest replacing <source></source> with <syntaxhighlight></syntaxhighlight>. Cheers
There has been a change to the personal tools here that was announced at the enwiki technical village pump. A change needs to be made to the "My new messages" to drop the possessive voice like the others. Any gadgets that modifies the personal tool links should also be checked and if nessary changed.
Please fine a bug in bugzilla: in regards to the liquid threads link (new messages).
Looks like this has already been fixed in gerrit:33105. I expect it'll be deployed with 1.21wmf5 on Monday 26th.
Turns out it can be done temporarily by changing a system message.
- MediaWiki:lqt-newmessages-n - New messages ($1)
Thanks for your help.
I noticed Template:MW legacy branch number has not been updated after the current version was bumped to 1.20, so that while {{MW legacy release number}} shows 1.19.4, {{MW legacy branch number}} is still 1.19. (And all these templates are locked, so I cannot fix them myself.) Maybe a comment should be included in those templates, so that none of them is forgotten on future updates?
Fixed. Generally this should be changed after looking at Category:MediaWiki version information templates.
There seems to be a thread stuck in my "new messages" queue.
I click the link which (currently) says I have 31 messages waiting but now, having marked as many as possible as "read", there is a single message showing with no button to mark it as read.
Help?
The message list is implemented by the LiquidThreads extension (not part of the MediaWiki software) which is installed on MediaWiki.org.
This bug has been reported before, see bugzilla:31251.
First page |
Previous page |
Next page |
Last page |
