Re: [Wikitech-l] Identifying potential cross-language contributions
Hoi, As you know all articles about the same subject are linked together thanks to Wikidata. Many articles refer to the same subjects. This concept cloud includes what was considered important when writing these articles. The content of this "concept cloud" can be seen from the "Reasonator" for any subject. It is on the right under all the links the article refers to. This [1] is the concept cloud for Mr Carl Sanders a former governor of Georgia. As you know, Reasonator will show you all information about a subject. All it takes are the labels used for *your* language. It is available now and it beats waiting for an article that may never come in *your* language. Adding labels is easy once Widar has been set up; you do it from the Reasonator itself. Thanks, GerardM [1] https://tools.wmflabs.org/wikidata-todo/cloudy_concept.php?q=Q888924 On 16 November 2014 23:49, Chas Leichner wrote: > I have noticed that there are a lot of pages which are extremely well > developed in one language and not particularly well developed in other > languages. I have been thinking about making tools to help identify and > translate these articles. What tools and approaches have been developed to > address this problem already? Have there been any projects to this effect? > > Regards, > Chas > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On Mon, 17 Nov 2014 19:56:04 +0100, James Forrester wrote: Maybe we should make the (read only) "your content" box more prominent, appearing before the "current content" one? Not sure this would help more than it would hinder everyone for the order to be reversed. I've always thought that the reason for the current ordering is so that people don't blindly press "Save" again and undo others' changes. -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
I think it would be ok to have a second "Save page" prompt that offers to save the page in a user's userspace. The save location could be something like User:Jimbo\editconflicts\pagename Auto-deletion of the edit conflict save would not be necessary. I also like Zack's suggestion. I think that could work with differences highlighted between the two versions: "EDIT CONFLICT. Another user has edited the page between the time that you started your edit and the time that you saved the page. But don't worry, you can reconcile the differences." YOUR VERSION OTHER VERSION +-+ +-+ | (read only | | (read only | | text area) | | text area) | | (background | | (background | | greenish) | | yellowish) | +-+ +-+ "Please merge the two versions into the text area below and then press save." +- -+ | (editable text area) | | (background white) | | (prefilled with the best | | 3-way merge we can manage) | +--+ Pine ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] composer validate now running for all extensions and skins
Le 17/11/2014 22:46, Legoktm a écrit : > Hi! > > With some help from bd808 and hashar, all extensions and skins now[1] > have a "php-composer-validate" job, which will run "composer > validate"[2] if your extension/skin's composer.json file is edited. > > Some extensions are still not passing validation, so I've uploaded[3] > some changes to make them all validate. Reviews appreciated :) Thank you a ton to have worked on that, much appreciated. That was a good opportunity for me to write the first integration test for the Zuul configuration files. More to come hopefully. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] composer validate now running for all extensions and skins
Hi! With some help from bd808 and hashar, all extensions and skins now[1] have a "php-composer-validate" job, which will run "composer validate"[2] if your extension/skin's composer.json file is edited. Some extensions are still not passing validation, so I've uploaded[3] some changes to make them all validate. Reviews appreciated :) -- Legoktm [1] https://gerrit.wikimedia.org/r/#/c/173457/ [2] https://getcomposer.org/doc/03-cli.md#validate [3] https://gerrit.wikimedia.org/r/#/q/status:open+topic:composer-validate,n,z ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC about extensions continuous integration
Hello, I have published a draft RFC about testing MediaWiki core and the extensions all together in a single job. As a first step limited to the extensions deployed on the Wikimedia cluster. That would let us catch tricky dependencies such as an incompatible change in Mantle breaking Flow and MobileFrontend. Currently, a change made to Mantle does not run the tests of other extensions depending on it. The RFC aims to solve it From the RFC: We will first present how Zuul establish states of repositories for a given patchset, then the utility that makes it trivial to reproduce such a state on a Jenkins slave taking for example the mediawiki/core and mediawiki/vendor tight integration that is being used today. Finally we will propose to extend such system to all MediaWiki extensions deployed on the Wikimedia cluster. The link: https://www.mediawiki.org/wiki/RFC/Extensions_continuous_integration -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On 16 November 2014 16:27, svetlana wrote: > On the second edit conflict, I read the message at the page top. It says: > > Someone else has changed this page since you started editing it. The upper > text area contains the page text as it currently exists. **Your changes are > shown in the lower text area.** You will have to merge your changes into > the existing text. Only the text in the upper text area will be saved when > you press "Save page". > > Emphasis added by me. We all know that people fail to read though. If we > can come up with a more colorful error message or a more intuitive edit > conflict page layout, I'm all ears. > However, any "colourful" message will likely get ignored more, not seen more – a problem which is exacerbated by wikis modifying many of the most common messages to be colourful. See https://en.wikipedia.org/wiki/Banner_blindness for more. > As to (semi-automatic) conflict resolution, our diff viewer probably has > to be fixed first - any conflict resolution starts with identifying the > differences, and our diff viewer fucks up at smallest possible edits or > problems as soon as an extra line break is involved, i.e. > https://test.wikipedia.org/w/index.php?title=User%3AGryllida&action=historysubmit&diff=218760&oldid=218759 > (Were the first sentence edit and second sentence edits made separately, > and with a conflict, the logic would die (esp. with an extra line break > change involved inbetween)). > Moving to character-level rather than paragraph-level diffing might help here, potentially. I vaguely remember that we attempted that and abandoned it because it caused more issues than it solved back in ?2004, though. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On 16 November 2014 14:36, Pine W wrote: > James: would it be possible to automatically save the text of a page to a > user's sandbox when they encounter an edit conflict? This would overwrite > the content of the sandbox, but that could be reverted using the normal > history page for the sandbox. > Hmm. Publishing content without the user clicking the "Save page" button a second time feels very icky. Also, would we need to go around and auto-delete these for users once the edit conflict was fixed? This doesn't sound like a perfect solution. There's also the issue with "the user's sandbox" not existing as an actual thing, just a hack that a couple of wikis have invented… Maybe we should make the (read only) "your content" box more prominent, appearing before the "current content" one? Not sure this would help more than it would hinder everyone for the order to be reversed. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] broken server-side SVG rendering of a VisualEditor icon
rsvg (the program Wikimedia wikis use to convert SVG to PNG) is unable to correctly parse some of the SVG files used for various icons in VisualEditor (and OOjs UI). We know about it and doing something about this is on our radar. -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] broken server-side SVG rendering of a VisualEditor icon
On Mon, Nov 17, 2014 at 12:43 PM, Amir E. Aharoni < amir.ahar...@mail.huji.ac.il> wrote: > I guess that either something is broken in the SVG file or in MediaWiki's > server-side SVG to PNG rendering. > Well, that is definitely not the only SVG file with problematic rendering. See https://commons.wikimedia.org/wiki/Category:SVG_compatibility_issues and https://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg_bug -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] broken server-side SVG rendering of a VisualEditor icon
Hi, I uploaded the following file to Commons: https://commons.wikimedia.org/wiki/File:VisualEditor_MediaWiki_theme_clear_icon.svg The file is taken form the VisualEditor repo: extensions/VisualEditor/lib/ve/lib/oojs-ui/themes/apex/images/icons/clear.svg If it's viewed on the above file description page, the appearance is broken: I see a partial circle and a rectangle. If I view it directly in my browser then it appears correctly as a circle with a diagonal line: https://upload.wikimedia.org/wikipedia/commons/7/7a/VisualEditor_MediaWiki_theme_clear_icon.svg I guess that either something is broken in the SVG file or in MediaWiki's server-side SVG to PNG rendering. Any ideas? Thanks. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Identifying potential cross-language contributions
On Sun, Nov 16, 2014 at 8:49 PM, Chas Leichner wrote: > I have noticed that there are a lot of pages which are extremely well > developed in one language and not particularly well developed in other > languages. I have been thinking about making tools to help identify and > translate these articles. What tools and approaches have been developed to > address this problem already? Have there been any projects to this effect? The tool http://tools.wmflabs.org/not-in-the-other-language/ can be helpful for this. See details on https://www.mediawiki.org/wiki/Topic:S5khz67yn6i68aew Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Identifying potential cross-language contributions
2014-11-17 10:13 GMT+02:00 svetlana : > On Mon, 17 Nov 2014, at 09:58, Amir E. Aharoni wrote: > > There's the ContentTranslation project - an extension to help people > > translate articles. Among other things, this project has a feature that > > suggests people who (probably) know two (or more) languages to write a > > translation for an article when there is no article in one of the languages > > that they know. This feature is being tested on the beta site: > > https://blog.wikimedia.org/2014/11/03/announcing-the-second-version-of-the-content-translation-tool/ > > How can we get it into the beta features tab -- at ALL sister projects (except commons etc where translating stuff is complex, it is all showed into one page atm, they did not switch to the subpages thing like Meta does, yet) -- please? > > Have a couple non-Wikipedias in mind where I'd use it actively. That is the eventual plan. The "subpages on Meta", which you mention, is the Translate extension, and it's a separate product, even though it's developed by the same team. The Translate extension is targeted at translating software UI strings (most notably at translatewiki.net) and at relatively simple, well-structured and rarely changing pages, such as newsletters, software user guides, etc. The advantage of Translate is that it keeps the translation in sync with the source and marks the parts that needs updating. It works fairly wel for Meta, Commons and mediawiki.org. ContentTranslation is for Wikipedia articles, which are more loosely structured, more richly formatted and frequently updated. Because of these challenges it's hard to track updated parts in the way that the Translate extension does, so ContentTranslation is positioned at this point as an article creation tool (though in the future it may acquire the ability to track changes, too). Unlike the Translate extension, ContentTranslation creates complete independent pages in language projects and not synched subpages in the same wiki. So yes - the plan is to get the tool deployed to all languages and to all relevant sister projects eventually (but gradually). Wikivoyage is an obvious candidate, and possibly Wikibooks if the communities are interested. Probably not Wiktionary, which needs a completely different direction, like OmegaWiki or Wikidata. Non-Wikimedia sites are welcome to use ContentTranslation, too. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Identifying potential cross-language contributions
The two main tools for this purpose are: * https://tools.wmflabs.org/wikidata-terminator/ * https://meta.wikimedia.org/wiki/Mix%27n%27match (both build on the redlinks/missing articles tradition). Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] searching across all languages
Install wdsearch on your account or wiki. https://en.wikipedia.org/wiki/MediaWiki_talk:Wdsearch.js Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Identifying potential cross-language contributions
How can we get it into the beta features tab -- at ALL sister projects (except commons etc where translating stuff is complex, it is all showed into one page atm, they did not switch to the subpages thing like Meta does, yet) -- please? Have a couple non-Wikipedias in mind where I'd use it actively. On Mon, 17 Nov 2014, at 09:58, Amir E. Aharoni wrote: > There's the ContentTranslation project - an extension to help people > translate articles. Among other things, this project has a feature that > suggests people who (probably) know two (or more) languages to write a > translation for an article when there is no article in one of the languages > that they know. This feature is being tested on the beta site: > https://blog.wikimedia.org/2014/11/03/announcing-the-second-version-of-the-content-translation-tool/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
