The Wayback Machine - https://web.archive.org/web/20160605081755/https://www.mediawiki.org/wiki/Project:Current_issues

Project:Current issues

Jump to: navigation, search

About this board

This page is for discussing issues related to MediaWiki.org site. To get help with MediaWiki software, ask on Project:Support desk.
Archives 

Current issues archive overview

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

Using watchlist notice for Code of Conduct calls for feedback

2
Qgil-WMF (talkcontribs)

At Talk:Code_of_Conduct/Draft#Wider_participation.2C_still there is a discussion about how to announce calls for feedback about the proposed Code of Conduct for technical spaces to mediawiki.org contributors. The idea of a watchlist notice has been suggested. As far as I am aware, we haven't used this feature in mw.o before. I guess this is a good place to ask for feedback about using this feature for this purpose.

Technically, this seems to be done by editing MediaWiki:Watchlist-details. Questions:

  • Is this use of watchlist notice OK or not?
  • Should we do it by editing MediaWiki:Watchlist-details or is there another way?
  • Should we use plain text with links or i.e. a Template:Notice?
  • How often and how long should these notices be kept, i.e. One week every time that there is a major call for feedback or more often?
Jdforrester (WMF) (talkcontribs)

Personally, I really dislike the abuse of that part of the interface for important messages, but I understand that some wikis think it's OK. We've never done it here, and I'd be sad to see it start.

More objectively, however, I also think it would be a waste of time for this wiki; very few people are active on MediaWiki.org in the way that editors of other wikis are, because a lot of the "action" occurs off-wiki, in tasks (Phabricator), in code (gerrit/GitHub/etc.), or for third party users of MediaWiki in particular, on their local systems, and so the use of the watchlist as the key place people see is not likely to work. The people who use their watchlists on this wiki (like me) are mostly wiki gnomes rather than the key people to involve. A logged-in-only sitenotice would probably have a much better effect at reaching the useful people for this work.

Reply to "Using watchlist notice for Code of Conduct calls for feedback"

Enabling Extension:Newsletter

3
Summary by Qgil-WMF

Resolving, after leaving a prudential time for feedback.

Qgil-WMF (talkcontribs)

The team developing Extension:Newsletter would like to have it enabled in mediawiki.org as soon as we complete its security review. We think it will be useful for mediawiki.org users willing to create or subscribe to newsletters. This extension can be tested in the Beta cluster and in its own instance in Labs.

The Newsletter extension project started a year ago as a Google Summer of Code project. The prototype was successfully completed by @Tinaj1234 during her internship. Since then, she has continued working in the project together with other volunteers, mainly @01tonythomas, @Glaisher, @Addshore, and @Parent5446.

Peachey88 (talkcontribs)

Most publications and related seem to happen at meta which would make it seem like a much better deployment location than mw wiki

Qgil-WMF (talkcontribs)

Yes, but also for this reason we want to start using the extension in production here (in a tech friendly environment filled with users familiar with reporting bugs & feature requests, and even with contributing documentation and patches) before jumping to the top leagues at Meta, en.wiki, etc.

Possible uses of this extension in mediawiki.org include

Wikimania 2016: call for posters, discussions and trainings

1
Summary by Qgil-WMF

The call is closed.

Yiyi (talkcontribs)

Hi people,

the calls for posters, discussions and trainings for Wikimania 2016 are officially opened, you can find all the relevant links on the conference wiki:

https://wikimania2016.wikimedia.org/wiki/Submissions

The calls will be closed on March 20.

Posters will be reviewed just to make sure that there aren't things which are too much out of scope. Since we have a whole village we will surely find places to attach them, even if we they will be a lot!

Discussions will be managed by a guiding committee who will work on the wiki to meld all the proposals and suggestions.

Trainings will be reviewed by the programme committee. Please note that we request that each training has at least 3-5 interested attendees in order to be put in the programme.

By the beginning of April we will have a first list of all the accepted proposals.

If you have questions we suggest you to ask them on the discussion pages on wiki, so that everyone will be able to see them (and their answers, of course).

We are looking forward to read your ideas!

Making the introduction email for new mw.org accounts more welcoming/useful

1
Summary by Qgil-WMF

Task resolved.

AKlapper (WMF) (talkcontribs)

Hi everybody,

in Wikimedia's task tracker in https://phabricator.wikimedia.org/T85601#2019740 there is a proposal to improve MediaWiki:Confirmemail body by adding some explanations and providing some helpful links, to make it a bit closer to Template:Welcome. Any feedback on that Phabricator task is welcome over there! (See Phabricator/Help#Creating your account if you have not been active in our issue tracker before.) Thanks for your input and making it easier for newcomers to find their way!

Cross-wiki notifications available as a Beta feature by February 19th

5
Summary by Qgil-WMF

Announced and deployed.

Trizek (WMF) (talkcontribs)

Hello!

Collaboration team is please to announce that Cross-wiki notifications will be available as a Beta feature on MediaWiki by February 19th at 01h00 UTC.

Cross-wiki notifications will help you know about some activity on another wiki. How does it work? Imagine someone thanks you on Commons - the next time you open a page on MediaWiki, you'll see that notification from Commons! We hope this will help everyone who is active on multiple wikis. You will find more information in the documentation.

Of course, this is a Beta Feature. We have tested many possible cases, but you may experience some problems. If so (and we are sorry about that), please report it on the dedicated page (in any language).To activate the feature, go to your preferences, Beta tab, and select the "Enhanced notifications" checkbox. You will then receive Notifications on MediaWiki when they happen on any other wiki. You will receive these notifications only on MediaWiki or any wiki where you have activated the feature (Beta testers: Wikidata, MediaWiki, Commons, all Hebrew and French wikis).

If you do not activate it, nothing will change on your Notifications panel.

If you have any questions, please ask!

Be..anyone (talkcontribs)

Looks good, but after enabling it locally on c: d: and mw: I hope there will be a way to enable it globally for the rest of the zoo.

Trizek (WMF) (talkcontribs)

Be..anyone, I've reported your idea, but I'm afraid that will require to create Global Preferences, which is a heavy and not scheduled work. :/

Be..anyone (talkcontribs)

No problem, meanwhile I found that "enabled on c: d: + mw:" actually covers everything visible while I'm on one of the "enabled sites": I got a few pending (old) dewiki + enwiki notifications (after some months offline) on commons.

Trizek (WMF) (talkcontribs)

To receive old notifications is perfectly normal.

I hope you really enjoy Cross-wiki notifications!

Enabling automatic translation engines in mediawiki.org

5
Summary by Qgil-WMF

Translation engines were enabled.

QuimGil (talkcontribs)

There is a lot of documentation translation work being done in mediawiki.org. Unless I am missing something, all of it is being done manually.

The Translate extension allows the integration of automatic translation engines. This would save a lot of work to translators, who currently are either typing manually or are copying & pasting from external translator engines.

ThurnerRupert (talkcontribs)

automatic translation engines have such a bad quality, the browser is much better in doing such things. translation support would be very much appreciated, but the current technology is unfortunately not usable and producing sub-standard mess. see https://meta.wikimedia.org/wiki/Grants:IdeaLab/de (idealab, german). click e.g. on "share ideas" - you are ending up on the english page. the page is marked 100% complete despite.

Qgil-WMF (talkcontribs)

I'm using the Translate extension with automatic translation support in translatewiki.net and it is useful. Anyway, this is a flexible feature. If someone doesn't want to use the suggested translations, they don't have to use them. But I see no reason to avoid that translators willing to give them a try have the chance to do it. All the technologies involved are open source, so more usage means more potential for improvement.

181.75.179.98 (talkcontribs)

I suggest to add an option for manual translation and bot translation, identify it with something "es" for translations by humans and "es (bot)", for translations by computers.

Qgil-WMF (talkcontribs)

The Translate extension simply offers the automatic translation in a side box. If the translator wants to use that translation, then they have to click it, and that text moves to the main textarea. There, the translator can polish the translation.

If the translator doesn't want that offered automatic translator, then they can type the translated message in the main textarea from scratch.

Usually the workflow is:

  1. Take suggested translation with a single click.
  2. Review the automatic text and edit wherever it is needed.
  3. Save.

Starting from an automatic text usually saves work. If in your specific text or language pair you see that this is not the case, you can just ignore it.

Nemo bis (talkcontribs)

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:

  1. Most viewed pages: I've done some, but they often need an update/revamp in English too.
  2. 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.
  3. 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.
Leucosticte (talkcontribs)

About #3: What about the users of non-WMF wikis? Wouldn't translated help pages be helpful for them?

Nemo bis (talkcontribs)

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.

Leucosticte (talkcontribs)

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.

HappyDog (talkcontribs)

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.

Nemo bis (talkcontribs)

Seems we can all agree on this, so we're left with #1 and #2 for now.

Nemo bis (talkcontribs)

So... no interest/ideas/suggestions on those two points (priority pages and manual pages)?

Leucosticte (talkcontribs)

I'm afraid translation isn't my area of expertise. It's been noted that "English is the working language of the Internet", though, and my attitude toward those who seek to administer websites tends to be, learn English or GTFO. But you seem to be on the right track as far as prioritization is concerned; focus on the most-viewed pages first.

Nemo bis (talkcontribs)

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.

Qgil-WMF (talkcontribs)

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:

  1. 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)...
  2. 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.

This post was posted by Qgil-WMF, but signed as Qgil.

Nemo bis (talkcontribs)

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.

Qgil-WMF (talkcontribs)

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."

This post was posted by Qgil-WMF, but signed as Qgil.

Nemo bis (talkcontribs)

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?

Qgil-WMF (talkcontribs)

Thank you for this useful link!

This post was posted by Qgil-WMF, but signed as Qgil.

This comment was hidden by Elitre (WMF) (history)
Reply to "Translate extension"
Elitre (WMF) (talkcontribs)

MyBot stopped working last year :/ https://www.mediawiki.org/w/index.php?title=Localisation_statistics&action=history

This comment was hidden by Ciencia Al Poder (history)
Glaisher (talkcontribs)

I just ran the script locally and updated that page (diff). It looks like transstat.php is throwing a bunch of PHP warnings (see phab:T135013). Maybe that's why it's broken? Unfortunately, MyBot's owner doesn't seem to be active.

Elitre (WMF) (talkcontribs)

Now, where do I go to find more Glaishers.

Reply to "Localisation stats are out-of-date"
Tactica (talkcontribs)

Please take a look here:

https://www.mediawiki.org/wiki/Topic:T3kqbcx79np5nyiq

As an editor, I have enough problems having to deal with tags in sources added by the Translate extension, but I didn't expect a language admin to revert a change of mine meant to improve the documentation just because it suits his particular translation. I was trying to remove a blatant redundancy in the source, yet he won't accept the change because "it is fine as it is" for the Japanese translation, which I doubt very much...

I have no problems changing whatever I do wrong, but this isn't the case here.

CZauX (talkcontribs)

yeah, there's enough issues with outdated docs, rather support those trying to update things. The old translations are kept, just because its translated doesn't mean that it can't or shouldn't be updated.

Krenair (talkcontribs)

I agree with @Tactica amiga, it's redundant in that page. It shouldn't matter whether the page has been marked for translation or not.

Shirayuki (talkcontribs)

Translation unit 13 should be rewritten without removing the unit 14.

Tactica (talkcontribs)

@Shirayuki Here's a novel idea: translate the *whole* page into Japanese, not only the lists and the captions in it. Maybe then you realize something is wrong.

Other than that I don't have much more to say on the matter except claim that this is an act of sabotage against the whole translation effort here.

Tactica (talkcontribs)

https://www.mediawiki.org/w/index.php?title=Manual%3AContents&type=revision&diff=2125243&oldid=2125216

Who promoted this guy to language admin? There are strings on that page which CANNOT be translated as it is ATM, just look at the Spanish version (I'm presuming the Japanese version is a hack). He keeps undoing changes arbitrarily so unless this is resolved TODAY I'm saying f*** it all.

(Update: OK, now I understand what he meant with translating stuff in the linked pages. But the point remains that the change is benign anyway, he keeps undoing changes just for the heck of it.)

Shirayuki (talkcontribs)

Feel free to fix Translations:Manual:System administration/Page display title/es.

Reply to "Edit dispute re: Help:Extension:Translate/Translation example"

Navigation menu

Personal tools

Variants

Views

More

In other languages

Morty Proxy This is a proxified and sanitized view of the page, visit original site.