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

MWException on removing qqq pages

2
Summary by Glaisher

Bug fixed.

Shirayuki (talkcontribs)

On removing qqq pages, MWException occurs e.g. Translations:Do not hack MediaWiki core/30/qqq

Legoktm (talkcontribs)

Filed as phab:T134962.

Tactica amiga (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 amiga (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 amiga (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"
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"
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"

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"