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
Elitre (WMF) (talkcontribs)

Read the overview at VisualEditor/Single edit tab. Many thanks.

ThurnerRupert (talkcontribs)

please set the default to two tabs.

Zppix (talkcontribs)

Look at your preferences, under editing what you're looking for should be under there

Reply to "Single edit tab at this wiki"
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)
Reply to "Localisation stats are out-of-date"
Shirayuki (talkcontribs)

The "mark for translation" link does not work!

Ciencia Al Poder (talkcontribs)

where?

Shirayuki (talkcontribs)

e.g. Help:Extension:ParserFunctions

Elitre (WMF) (talkcontribs)

https://phabricator.wikimedia.org/T128638 Quoting: "You can use any of the following to work-arounds:

  • Append &do=mark to the url
  • Go via Special:PageTranslation"
Shirayuki (talkcontribs)

Thanks!

Elitre (WMF) (talkcontribs)

Don't mention it!

Shirayuki (talkcontribs)

Additionally, do=unmark does not work. e.g. Wikimedia Discovery/Knight FAQ should be unmarked.

Elitre (WMF) (talkcontribs)

Can you report this on Phab?

Shirayuki (talkcontribs)

I have reported at https://phabricator.wikimedia.org/T129044

This comment was hidden by Ciencia Al Poder (history)
This comment was hidden by Ciencia Al Poder (history)
Reply to "Unable to mark for translation"

Update translation status of Manual:User rights

2
Ciencia Al Poder (talkcontribs)

The translation status of Manual:User rights needs to be refreshed or whatever, so translated pages receive update of the translation units. For example, the description of rights is retrieved from {{int|right-editmyprivateinfo}}, whereas translated pages have the plain text for translating

This comment was hidden by Ciencia Al Poder (history)
Reply to "Update translation status of Manual:User rights"
Clump (talkcontribs)

The 2015-12-21 link on the main page under news for maintenance updates (https://lists.wikimedia.org/pipermail/mediawiki-announce/2015-December/000187.html) points to a mailing list post which includes links to versions and corresponding GPG signatures. However, the links in that post that point to the .sig files for the full updates are all misnamed, and hence broken. Testing one of them, it seems like the "tar" suffix was dropped; for example,

https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.5.gz.sig

should be

https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.5.tar.gz.sig

Ciencia Al Poder (talkcontribs)

There's nothing much to do, since we can't edit messages in lists, but you may want to open a bugreport about that and assign it to User:^demon so he's aware of that and to avoid the same typo on next releases

AKlapper (WMF) (talkcontribs)

See Phab:T128344.

This comment was hidden by Ciencia Al Poder (history)
Reply to "Missing GPG signatures for MW updates"
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)
41.178.227.96 (talkcontribs)

arabic language

Reply to "Translate extension"

Enabling automatic translation engines in mediawiki.org

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

Reply to "Enabling automatic translation engines in mediawiki.org"
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

Reply to "Enabling Extension:Newsletter"
Wargo (talkcontribs)

Why it is not respected? When someone visit this domain it redirects to english main page.

Ciencia Al Poder (talkcontribs)

Sidebar displays the main page correctly when the user language is set to pl, but the logo and the www.mediawiki.org domain does not. I guess the main page is not respecting the localization, which it makes sense, since default MediaWiki installation has localized main page titles which won't have any content on the vast majority MediaWiki installations.

However, changing this seems to be possible as described in Manual:$wgForceUIMsgAsContentMsg. You can report it to phabricator so this setting is enabled for mainpage.

Wargo (talkcontribs)

Yes, this may be this variable. I found this for Meta and it works. Result I expect is if user set, for example PL, then if type only mediawiki.org then it show MediaWiki/pl as the main page instead MediaWiki.

Reply to "Localized main page"

MediaWiki/Wikipedia user account consolidation : how to handle talk pages?

5
Egfrank (talkcontribs)

Several years ago (2007) I was very active on both MediaWiki and Wikipedia and of course had two accounts - one on each wiki. I am now getting active again, and just discovered that in 2015 my MediaWiki account User: Egfrank was deleted and moved to User: Egfrank~mediawikiwiki.I thought at first this meant that I would have one user account that would work on both Wikipedia and MediaWiki and that I could have a single talk page to handle messages from both wikis. However, if messages concerning MediaWiki are posted on my Wikipedia talk page - full URLs need to be used to reference mediawiki articles - which is not terribly convenient for me or anyone having to contact me. If I direct traffic to User talk:Egfrank (on MediaWiki) then I and people trying to contact me can use MediaWiki namespaces for links, BUT now I have (a) a talk page without a user (b) two talk pages to track rather than one.

So what is the best way to handle this?

1. Is there some way to use namespaces to link to MediaWiki user accounts and pages from within Wikipedia? It is not convenient to have to cut and paste long URLs in messages. Additionally there is room for error and miscommunication if someone is talking to me on Wikipedia about MediaWiki business - if there are links to articles in both MediaWiki and Wikipedia, the person will see a blue link and think they are leaving a MediaWiki link when in fact they are leaving a Wikipedia link.

2. Should I revert the delete of my mediawiki user page? If there is no way to handle the linking problem, then I really do need two talk pages, one on mediawiki and one on wikipedia. A talk page without a user page seems rather odd and confusing.

Best, User: Egfrank / User: Egfrank~mediawikiwiki (on MediaWiki)

https://en.wikipedia.org/wiki/User:Egfrank (on Wikipedia)

Ciencia Al Poder (talkcontribs)

About namespaces maybe you mean interwiki links. You can use [[w:User:Egfrank]] to link to your wikipedia user, and [[mw:User:Egfrank~mediawikiwiki]] to link to your mediawiki user page

About your account, apparently you have 2 separate accounts here, one of them (the one with ~mediawikiwiki) is the old one, while the other is the one handled with CentralAuth. You probably could login with the ~mediawikiwiki one too.

I don't know if someone can merge both accounts here, but if not, you can move the page User:Egfrank~mediawikiwiki to User:Egfrank, put a redirect in place, or writing a notice about your current page location.

Egfrank (talkcontribs)

Indeed I did mean interwiki links - thanks for the "how to do this". I moved the egfrank~mediawikiwik pages back to User:egfrank without a problem - merge was not necessary since there hasn't been activity for years (aside from one very recent message). But I have a new problem: the restored user talk page is in the old format rather than in "Flow" mode. Is it possible to convert the page to Flow? I checked on Flow/Request_Flow_on_a_page but the section on individuals seems to be about individuals requesting flow on wikis before their wikis have adopted flow, rather than fixing a user talk page that got left behind when user pages were converted to flow.

Ciencia Al Poder (talkcontribs)

Apparently you can enable it on your talk page activating it in your preferences, under beta features: Special:Preferences#mw-prefsection-betafeatures

Egfrank (talkcontribs)

Many thanks again!

Reply to "MediaWiki/Wikipedia user account consolidation : how to handle talk pages?"