Re: [Wikitech-l] Making inter-language links shorter
On 04/18/2013 06:50 PM, Pau Giner wrote: As multilingual content grows, interlanguage links become longer on Wikipedia articles. Articles such as Barak Obama or Sun have more than 200 links, and that becomes a problem for users that often switch among several languages. For how many users is this a problem? How do you estimate this? I think it's good that the user is a little overwhelmed with how many languages are available. The use of Geo-IP will be interpreted as a political tool that tries to enforce certain languages in certain geographic areas, which would be contrary to the mission of the Wikimedia Foundation, that says all the world's knowledge in your own language. If a user finds it offensive that an article is available in some languages that she somehow dislikes, let her login and select which ones should be hidden. The burden should be on that user. Wikipedia should provide knowledge, not hide it. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making inter-language links shorter
Le 2013-04-19 12:05, Lars Aronsson a écrit : On 04/18/2013 06:50 PM, Pau Giner wrote: As multilingual content grows, interlanguage links become longer on Wikipedia articles. Articles such as Barak Obama or Sun have more than 200 links, and that becomes a problem for users that often switch among several languages. For how many users is this a problem? How do you estimate this? I think it's good that the user is a little overwhelmed with how many languages are available. The use of Geo-IP will be interpreted as a political tool that tries to enforce certain languages in certain geographic areas, which would be contrary to the mission of the Wikimedia Foundation, that says all the world's knowledge in your own language. What a delight to see someone which is more paranoic than myself on this topic. ;) If a user finds it offensive that an article is available in some languages that she somehow dislikes, let her login and select which ones should be hidden. The burden should be on that user. Wikipedia should provide knowledge, not hide it. On the other hand cluter can be an effective way to hide or obstruct the access to information. -- Association Culture-Libre http://www.culture-libre.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Works on annotations
I think I red some things on annotations in the Visual Editor, but I
can't find it again. Do you have relevant informations on the subject? I
like to use template like {{why|blabla}} and {{according to
who|blabla}}, but in the same time I can see that while making a
contribution call to knowledgeable people, it can quickly clutter the
text with a lot of underlined sentances. So it may be interesting to
have an option to hide/show this kind of query.
--
Association Culture-Libre
http://www.culture-libre.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Heads up: small new feature in ConfirmEdit
On 19/04/13 00:21, Steven Walling wrote: Hi all, This is a heads up that we've added a small new feature which hopefully will make things less painful for users across the projects: the ability to refresh the CAPTCHA you're presented without refreshing the entire page. It should work everywhere ConfirmEdit can throw the image CAPTCHA at someone: account creation, login, the edit form, etc. (It won't modify the simple math CAPTCHA, and so on.) The original enhancement request for this ( https://bugzilla.wikimedia.org/show_bug.cgi?id=14230) goes back to 2008. A patch was submitted back in January by lalei: https://gerrit.wikimedia.org/r/#/c/44376/ If you want to test this out yourself before it's deployed, you can use http://toro.wmflabs.org/wiki/Main_Page Great! Although, is Refresh the best term for the UI? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Support for 3D content
Hi, Reading the 2012-13 Plan, I see that multimedia is one the key activities for Mediawiki. So I was wondering if there was already any plan to integrate 3D model viewers, which would be for example very interesting for anatomy articles, or simply 3D maths objects. MediaGoblin[1] show that we already all the free software stack to do that, however I don't have enough data to estimate development charges of that kind of features into Wikimedia. [1] https://en.wikipedia.org/wiki/GNU_MediaGoblin -- Association Culture-Libre http://www.culture-libre.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Support for 3D content
On 04/19/2013 06:03 AM, Mathieu Stumpf wrote: Hi, Reading the 2012-13 Plan, I see that multimedia is one the key activities for Mediawiki. So I was wondering if there was already any plan to integrate 3D model viewers, which would be for example very interesting for anatomy articles, or simply 3D maths objects. http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#New_media_types_supported_in_Commons offers some interesting links to Commons discussions. MediaGoblin[1] show that we already all the free software stack to do that, however I don't have enough data to estimate development charges of that kind of features into Wikimedia. [1] https://en.wikipedia.org/wiki/GNU_MediaGoblin -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Support for 3D content
On Fri, Apr 19, 2013 at 6:03 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Hi, Reading the 2012-13 Plan, I see that multimedia is one the key activities for Mediawiki. So I was wondering if there was already any plan to integrate 3D model viewers, which would be for example very interesting for anatomy articles, or simply 3D maths objects. I know that work on PDBHandler is ongoing: http://www.mediawiki.org/wiki/Extension:PDBHandler ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Support for 3D content
You also have a Jmol extension http://www.mediawiki.org/wiki/Extension:Jmol It's working on wiki.jmol.org On Fri, Apr 19, 2013 at 4:45 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Fri, Apr 19, 2013 at 6:03 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Hi, Reading the 2012-13 Plan, I see that multimedia is one the key activities for Mediawiki. So I was wondering if there was already any plan to integrate 3D model viewers, which would be for example very interesting for anatomy articles, or simply 3D maths objects. I know that work on PDBHandler is ongoing: http://www.mediawiki.org/wiki/Extension:PDBHandler ___ 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] Support for 3D content
Hi! Extension and viewer for Chemical Markup Language were created long time ago. However it's still not reviewed for security issues to be included on WMF projects. See https://bugzilla.wikimedia.org/show_bug.cgi?id=16491. On Fri, Apr 19, 2013 at 6:03 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Hi, Reading the 2012-13 Plan, I see that multimedia is one the key activities for Mediawiki. So I was wondering if there was already any plan to integrate 3D model viewers, which would be for example very interesting for anatomy articles, or simply 3D maths objects. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Support for 3D content
Sounds like NicoV started work again to try to address those issues. We should take a look at the Amsterdam Hackathon or Wikimania. On Fri, Apr 19, 2013 at 10:54 AM, Eugene Zelenko eugene.zele...@gmail.comwrote: Hi! Extension and viewer for Chemical Markup Language were created long time ago. However it's still not reviewed for security issues to be included on WMF projects. See https://bugzilla.wikimedia.org/show_bug.cgi?id=16491. On Fri, Apr 19, 2013 at 6:03 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Hi, Reading the 2012-13 Plan, I see that multimedia is one the key activities for Mediawiki. So I was wondering if there was already any plan to integrate 3D model viewers, which would be for example very interesting for anatomy articles, or simply 3D maths objects. Eugene. ___ 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] WMF Engineering Roadmap Update - 20130417
quote name=K. Peachey date=2013-04-19 time=15:09:58 +1000 On Fri, Apr 19, 2013 at 8:54 AM, Rob Lanphier ro...@wikimedia.org wrote: We used to do that: https://www.mediawiki.org/wiki/Roadmap ... How about just something simple like * https://www.mediawiki.org/w/index.php?title=User:Peachey88/Sandbox/table2 or * https://www.mediawiki.org/w/index.php?title=User:Peachey88/Sandbox/table1 Mostly it is the function of multiple people editing the document together at the same time in the same room. Until that problem can be solved on wiki, then a big wiki table probably won't be functional, at least in the current form that we've taken for this. But, I also don't know the full capabilities of what could be done, here, so if someone has a suggestion on how to work this on wiki that allows easy multi-user simultaneous editing, please do let me know. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Survey: best times for volunteering
On Mon, Apr 15, 2013 at 9:41 PM, Quim Gil q...@wikimedia.org wrote: Hi, please find 5 minutes for this survey: http://www.doodle.com/minqnd6ngz9npfdv 22 people answered. If you couldn't find the time yet please do it before the end of the week. We are simply asking in which time slots you are most likely available during a regular week. We don't want to default to working hours in San Francisco just by inertia. The survey is anonymous. That's all. VERY IMPORTANT: select your timezone! Deadline: end of Sunday, May 21. We want to organize activities for technical volunteers at the times that suit you best. But we have contributors with different habits in different parts of the World. This survey will help us covering better everybody's preferences. Thank you! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Engineering Roadmap Update - 20130417
Hi, On Fri, Apr 19, 2013 at 5:29 PM, Greg Grossmeier g...@wikimedia.org wrote: Mostly it is the function of multiple people editing the document together at the same time in the same room. Until that problem can be solved on wiki, then a big wiki table probably won't be functional, at least in the current form that we've taken for this. But, I also don't know the full capabilities of what could be done, here, so if someone has a suggestion on how to work this on wiki that allows easy multi-user simultaneous editing, please do let me know. Off the top of my head, and without thinking too much about it: Solution #1: All the content lives in [[Projectname/Roadmap]] pages, in monthly sections labeled with Labeled Section Transclusion. They can be transcluded into other pages (like a big all-encompassing Roadmap page, or smaller roadmaps per team / subdepartment). A JavaScript gadget allows for easy editing of roadmap items (i.e. cells) directly from the Roadmap page (and other transclusion pages) using a modal overlay, like the StatusHelper does ( https://www.mediawiki.org/wiki/MediaWiki:Gadget-WmfProjectStatusHelper.js ) Pros: * Everything is and stays on wiki. * The roadmap for each project can be maintained by the project's team more easily, because it's closer to the project page. * The JavaScript template hackery needed to make this work is probably not too complicated and can be inspired by the existing StatusHelper. * No edit conflicts, since people are editing different pages. Cons: * People can't simultaneously edit the same roadmap item (cell for a given month and a given project). * People need to refresh the page to see edits made by other people with the gadget. * Some template / LST / JavaScript dev work is required. Based on my understanding of how the roadmap is currently updated (each Tech director updates the roadmap for the projects that fall under their supervision), the cons don't seem unsurmountable. * Solution #2: All the content lives in a big table at [[Roadmap]] that can be edited simultaneously by users using a yet-to-be-developed round-tripping tool to an ethercalc instance in labs. Someone opens the page for editing in ethercalc, everyone makes their edits, and the content is saved back to the wiki page. Pros: * Everything lives on wiki. * People can simultaneously edit all parts of the document, including the same cells, and immediately see each other's changes Cons: * This requires significant dev work, probably not trivial considering the difficulties encountered when we tried to integrate regular etherpad with wikipage editing a few years back. * How do we handle edit conflicts? * This poses other questions like who is attributed for the edits, etc. An alternative to #2: the round-tripping is done manually by copy/paste or similar (as it used to be done when tech directors updated the roadmap in etherpad) if the conversion between formats isn't too lossy; This avoids having to develop an integrated round-tripping tool. Solution #3: A combination of #1 and #2: for example, the content lives in a big table at [[Roadmap]], and there's a round-tripping tool to an ethercalc instance in labs for collaborative editing, but there's also a JavaScript gadget to edit individual cells of the table. Note: LST can probably be replaced by Semantic MediaWiki if it's available on the wiki we're talking about. In a nutshell: I understand that the way the roadmap is currently updated (in a meeting of all tech directors each updating their sections) requires simultaneous editing of the /page/, but I'm not sure concurrent editing of /each cell/ is as crucial, so compromising on that may greatly simplify the problem. HTH, -- Guillaume Paumier Technical Communications Manager — Wikimedia Foundation https://donate.wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Tutorial on Semantic MediaWiki in Russian
Hi everyone! In Semantic MediaWiki we have great but very long documentation. I've tried to write a small introduction to SMW. It's only in Russian now (I know that some amount of Russian MediaWikers are reading this mailing list), but I think to write something similar in English (maybe to IBM DeveloperWorks). http://habrahabr.ru/post/173877/ If you don't know Russian you can enjoy the pictures anyway ;) Cheers, - Yury Katkov, WikiVote ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSOC idea : Mobilize Wikidata
Hi, My name is Yanna and I'm interested in this mobilizing Wikidata idea. I have read the thread about the topic and I agree with the idea that we can first use MobileFront to see the result. My suggestion regard to the data-editing feature is that we should remove the column of edit button and implement gestures recognition on each editable entry. The editing feature can be called upon certain gesture. Currently I can think of two solutions: 1. long press gesture. After a long press is detected, the edit or add menu should pop up, thus allowing the pressed entry to be modified. 2. Second tap detect. When the user first tap the entry, it becomes highlighted. If the highlighted entry is tapped again, then it turns to the state of being modified. So that's basically my suggestions, I'd like to hear about your opinions. I have some experience with PhoneGap, using html/css to build native mobile apps. I also have experiences with mobile app development (specifically ios app), so I'm familiar with the mobile UI development. I think my experience will help a lot in mobilizing Wikidata. I'm planning to apply for the GSOC AND the Outreach Program for Women. I'm looking forward to some suggestions about what I could contribute. Thanks, Yanna ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Several GSoC / OPW candidates after the same project (was Re: GSOC idea : Mobilize Wikidata)
Hello Yanna, thank you for your interest contributing to Wikimedia! On 04/19/2013 09:41 AM, Yanna Wu wrote: My name is Yanna and I'm interested in this mobilizing Wikidata idea. I have read the thread about the topic and I agree with the idea that we can first use MobileFront to see the result. Then you have probably seen that there is another candidate interested in this project as well. Showing proof of skills and previous projects is good for any applicant, but in cases with concurrent candidates it is even more important since we will need to choose between different people going after a same project. I can also imagine the situation in which we will prioritize one candidate over another, but we will still believe that the second candidate may have option get accepted with another project. Having a second project idea in mind will be good in these cases. We will do our best resolving priorities in these situations, in order to give as much time as possible to candidates working on an alternative project proposal. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [GSoc2013] Interested in developing Entity Suggester
Hi, I am a 3rd year undergraduate student of computer science, pursuing my B.Tech degree at RCC Institute of Information Technology. I am proficient in Java, PHP and C#. Among the project ideas on the GSoC 2013 ideas page, the one particular idea that seemed really interesting to me is developing an Entity Suggester for Wikidata. I want to work on it. I am passionate about data mining, big data and recommendation engines, therefore this idea naturally appeals to me a lot. I have experience with building music and people recommendation systems, and have worked with Myrrix and Apache Mahout. I recently designed and implemented such a recommendation system and deployed it on a live production site, where I'm interning at, to recommend Facebook users to each other depending upon their interests. The problem is, the documentation for Wikidata and the Wikibase extension seems pretty daunting to me since I have not ever configured a mediawiki instance or actually used it. (I am on my way to try it out following the instructions at http://www.mediawiki.org/wiki/Summer_of_Code_2013#Where_to_start.) I can easily build a recommendation system and create a web-service or REST based API through which the engine can be trained with existing data, and queried and all. This seems to be a collaborative filtering problem (people who bought x also bought y). It'll be easier if I could get some help about the part where/how I need to integrate it with Wikidata. Also, some sample datasets (csv files?) or schemas (just the column names and data types?) would help a lot, for me to figure this out. I have added this email as a comment on the bug report at https://bugzilla.wikimedia.org/show_bug.cgi?id=46555#c1. Please ask me if you have any questions. :-) Thanks, Nilesh -- A quest eternal, a life so small! So don't just play the guitar, build one. You can also email me at cont...@nileshc.com or visit my websitehttp://www.nileshc.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tutorial on Semantic MediaWiki in Russian
That is a nice starter guide! Thank you, Yury! On Fri, Apr 19, 2013 at 7:35 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! In Semantic MediaWiki we have great but very long documentation. I've tried to write a small introduction to SMW. It's only in Russian now (I know that some amount of Russian MediaWikers are reading this mailing list), but I think to write something similar in English (maybe to IBM DeveloperWorks). http://habrahabr.ru/post/173877/ If you don't know Russian you can enjoy the pictures anyway ;) Cheers, - Yury Katkov, WikiVote ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making inter-language links shorter
Thanks for all the feedback! I'll try to respond below to some of the issues raised: *Which is the problem?* As it has been mentioned, one of the most effective ways of hiding something is to surround it in the middle of a long list. This produces two problems: - *Lack of discoverability.* users may be not aware that the content is available in their language (which goes against our goal of providing access to knowledge). Speakers of small languages that access the English Wikipedia because it has more content, are forced to make an effort each time to check if each article is also available in their language. - *Problems for multi-lingual exploration.* It is hard to switch between multiple language versions since the users has to look for his languages each time in the whole list. The fact that some Wikipedias adjust the order of the languages, the existence of user scripts and an Opera extensionhttps://addons.opera.com/es/extensions/details/wikipedia-language-bubble/?display=en to solve the issue, is an indicator of the existence of such problem. We support lots of languages (+300) but users are normally interested in a small (1-8) subset of those. We need to make these subset easily discoverable for our users, and providing them in the middle of a list with 200 items is not the best way to do it in my opinion. *Possible cultural and value problems* As it was commented, the multilingual nature of Wikipedia is a strong held value. However, currently it is hard to know in how many languages an article is available since you need to count the links. With the proposed approach we provide a number which helps to communicate that. So I think we are not going against that value. I think that concerns about the imposition of languages per region are not a big issue when the previous user choices and the browser accept language are considered with more priority than Geo-IP. Users just need to select their language once and it will be appearing in the short list the next times. These concerns should be more relevant with the current situation where some Wikis put some languages on top regardless user choices (for some work 100% of the time, for others they fail 100% of the time). I also don't think that we should prioritise the need to hide languages that users somehow dislikes over making it easy to access the languages that the user wants. In any case, the former is also not supported with the current approach. *Why to hide?* I understand the problems commented when language links were initially hidden in Vector, since uses were required to make an additional step to get into the same long list of links we currently have. With the proposed approach, the extra step is only taken in exceptional cases (e.g., a user in a foreign country accessing from a public pc), and this is made only once (not for each language change), and aids such as search are provided to make it really quick. The reordering alternative has some problems compared with the proposed approach. For example, when a language does not appear on top, it is hard to determine whether the current article is not provided in that language or it is in the middle of the list. In addition, with reordering, you cannot rely on alphabetical order (while you can present the short list alphabetically). *Considering size and quality of the article* It can be a factor to consider since communicating that an article has good versions in other languages is a good thing. But I think it is a low priority one, since I find hard to imagine a user selecting a language which she does not understand (otherwise will be already in the short list) just because the article is of good quality. In any case, users normally speak 1-8 languages, so even in a relatively short list there is still room for other criteria. *The way to access more* We choose the ... so that the label could work across languages. So that you can go back to your language if you arrive by accident to a foreign Wikipedia (or you are an advanced user curious to check if web fonts were enabled in Javanese wikipedia). However, the visual execution needs some work still to make it more touch friendly among other things. *Details on the language list UI* The interactive prototype was created to communicate the main idea and most details are still lacking. Thanks for pointing layout and navigation problems. The layout of the list is one of the aspects that needs more work: currently we group the languages by script to help the user to recognise their familiar scripts, and the algorithm also makes some control of orphan/widow items. That works well for very long lists of languages, but needs further tuning when the number of elements is reduced. An algorithm that presents the list optimally for all possible lengths is something to be done. Pau -- Pau Giner Interaction Designer Wikimedia Foundation On Thu, Apr 18, 2013 at 6:50 PM, Pau Giner pgi...@wikimedia.org
Re: [Wikitech-l] Heads up: small new feature in ConfirmEdit
On 04/19/2013 07:59 AM, Platonides wrote: Although, is Refresh the best term for the UI? It should be pretty clear based on context and the icon. People have seen this before on other sites. However, it's easy to change the text later if needed. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Call for new list moderators
Hi everyone, As you may have remembered reading. Huib--our longtime volunteer moderator for mediawiki-l and wikitech-l--resigned from his positions back in February[0]. I let this slip longer than I should've, but I'd like to now make the call for a new batch of list moderators for mediawiki-l and wikitech-l. I think it's very important to have more than one moderator per list, so I'm looking for several candidates to help with moderation with one (or both) lists. It's a pretty low maintenance job (the occasional spammer), as Huib and myself have always had a very light-handed moderation policy and have preferred to let discussions run their course. So, if this is something you're interested in helping out with, please respond to this off-list and tell me why. Don't need an essay, just a sentence or two about who you are and why you'd like to volunteer. I'll give it a couple of days for people to think about it and e-mail me, and I'll pick some people by late next week. Thanks, and have a good weekend :) -Chad [0] http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066320.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Deployment Highlights Update - Week of April 22nd
Hello and welcome to the latest installment of the Deployment Highlights email. The full calendar for next week lives at: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_April_22nd For the week of April 22nd we have the following interesting deployments: == Monday == * MediaWiki 1.22wmf2 to English Wikipedia * Wikidata client update on English Wikipedia. Completion of Wikidata Phase II [0], which will allow for use of Wikidata properties in infoboxes. There is also an FAQ[1] about Phase2 that might answer your questions. [0] http://meta.wikimedia.org/wiki/Wikidata/Technical_proposal#Phase_2:_Infoboxes [1] http://meta.wikimedia.org/wiki/Wikidata/Deployment_Questions#Phase_2_.28infoboxes.29 == Tuesday == * ArticleFeedbackTool will be renabled to on on a subset of English Wikipedia, along with basic bugfixes to French and German Wikipedia. Details: http://etherpad.wikimedia.org/AFT5-release * Mobile: ** First use of CentralNotice to display banners for users of the WP Commons Beta app. ** Deploy of a fix for the X-Device caching problem explained in this[2] email. Basically, reduce the cache-miss rate by not varying the cache by 21 different device types. [2] http://lists.wikimedia.org/pipermail/wikitech-l/2013-March/067967.html == Wednesday == * MediaWiki 1.22wmf2 to all Wikis * Wikidata client update on all Wikipedia sites (tentative; depending on success of English Wikipedia deployment on Monday). == Thursday == * VisualEditor/Parsoid alhpa to be enabled on additional 14 wikis (but not by default, still opt-in). ** WPs included: de, nl, fr, it, ru, es, sv, pl, ja, ar, he, hi, ko, zh ** Announcement: http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-April/000201.html * Notifications: Releasing of the Minimum Viable Product on English Wikipedia. See these two ([3] [4]) messages from the Notifications Product Manager, Fabrice Florin, outlining what features are included. [3] http://lists.wikimedia.org/pipermail/ee/2013-April/000373.html [4] http://lists.wikimedia.org/pipermail/ee/2013-April/000390.html ** Full details: http://etherpad.wikimedia.org/echo-release == Everyday == And of course, every day includes the Lightning Deploy window, which this week is ceremonially referred to as Matt Walker's Deploy Window as he was a heavy (and courteous) user of these windows this past week. Thanks and have a good weekend, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [Language Engineering] Bug triage on Wednesday, April 24 2013 at 1700 UTC/1000 PDT
What: Translation User Interface bug triage Date: April 24 2013 Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0) Channel: #mediawiki-i18n (Freenode) Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-04 Questions can be sent to: runa at wikimedia dot org Hello, The Language Engineering team would like to invite everyone for the upcoming bug triage session on Wednesday, April 24 2013 at 1700 UTC (1000 PDT). During this 1 hour session we will be using the etherpad listed above to collaborate. We have already listed some bugs, but please feel free to add more bugs, comments and any other related issues that you’d like to see addressed during the session. You can send questions directly to me on email or IRC (nick: arrbee). Please see above for event details. Thank you. regards Runa -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Engineering Roadmap Update - 20130417
quote name=Greg Grossmeier date=2013-04-18 time=08:52:03 -0700 I'll work on copying over the current version of the Roadmap to ethercalc today/tomorrow. Actually, if anyone wants to help: https://ethercalc.org/WMF_Engineering_Roadmap I *think* all of the content is copied over, but the formatting needs some work ;-). I didn't see an import from CSV/xsl function, but if I missed that, it might be worth a shot. So, update on this. I haven't worked on the formatting part at all, really, because I can't find an export functionality. I don't think I should devote more time to the formatting until I know I can easily import/export the content for the near term. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] browser tests now targeting beta cluster
Over the last week Željko and I changed the QA automated browser tests to target test environments on the beta cluster as well as on test2wiki, where they had been running for some time. This was possible because of a number of improvements made to beta since the QA Quarterly Review and the f2f meeting in SF in February: * automatic updates to the beta database * enabling Search on beta * Varnish on beta to support MobileFrontend * etc. There is still more to do: * get more extensions running and configured on beta * change settings to more closely match prod and/or test2 as appropriate * moar tests Automated browser tests have a proven record of exposing real issues in the test2wiki environment before code is put in production. Here are some of the bugs we have identified by way of browser tests so far: https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=cmcmahon%40wikimedia.orgemailtype1=exactemailassigned_to1=1emailreporter1=1list_id=195485 By running these tests in the beta cluster also, we gain both better test coverage features in disparate environments and also a longer window to identify issues, since beta is updated much more often than test2wiki. As always, the current status of the browser test builds are available in Jenkins at https://wmf.ci.cloudbees.com, and any changes to the status of those builds are reported by wmf-jenkins-bot in #wikimedia-dev ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] browser tests now targeting beta cluster
quote name=Chris McMahon date=2013-04-19 time=14:12:47 -0700 Over the last week Željko and I changed the QA automated browser tests to target test environments on the beta cluster as well as on test2wiki, where they had been running for some time. This is awesome work, guys, thank you! Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Design] Making inter-language links shorter
Also, did you think of the accessibility issues in your solution? Here I especialy think of people with view disabilities, for who js often mean no way to get the content, while a long list of hyperlinks is manageable. Le vendredi 19 avril 2013 à 20:19 +0200, Pau Giner a écrit : Thanks for all the feedback! I'll try to respond below to some of the issues raised: Which is the problem? As it has been mentioned, one of the most effective ways of hiding something is to surround it in the middle of a long list. This produces two problems: * Lack of discoverability. users may be not aware that the content is available in their language (which goes against our goal of providing access to knowledge). Speakers of small languages that access the English Wikipedia because it has more content, are forced to make an effort each time to check if each article is also available in their language. * Problems for multi-lingual exploration. It is hard to switch between multiple language versions since the users has to look for his languages each time in the whole list. The fact that some Wikipedias adjust the order of the languages, the existence of user scripts and an Opera extension to solve the issue, is an indicator of the existence of such problem. We support lots of languages (+300) but users are normally interested in a small (1-8) subset of those. We need to make these subset easily discoverable for our users, and providing them in the middle of a list with 200 items is not the best way to do it in my opinion. Possible cultural and value problems As it was commented, the multilingual nature of Wikipedia is a strong held value. However, currently it is hard to know in how many languages an article is available since you need to count the links. With the proposed approach we provide a number which helps to communicate that. So I think we are not going against that value. I think that concerns about the imposition of languages per region are not a big issue when the previous user choices and the browser accept language are considered with more priority than Geo-IP. Users just need to select their language once and it will be appearing in the short list the next times. These concerns should be more relevant with the current situation where some Wikis put some languages on top regardless user choices (for some work 100% of the time, for others they fail 100% of the time). I also don't think that we should prioritise the need to hide languages that users somehow dislikes over making it easy to access the languages that the user wants. In any case, the former is also not supported with the current approach. Why to hide? I understand the problems commented when language links were initially hidden in Vector, since uses were required to make an additional step to get into the same long list of links we currently have. With the proposed approach, the extra step is only taken in exceptional cases (e.g., a user in a foreign country accessing from a public pc), and this is made only once (not for each language change), and aids such as search are provided to make it really quick. The reordering alternative has some problems compared with the proposed approach. For example, when a language does not appear on top, it is hard to determine whether the current article is not provided in that language or it is in the middle of the list. In addition, with reordering, you cannot rely on alphabetical order (while you can present the short list alphabetically). Considering size and quality of the article It can be a factor to consider since communicating that an article has good versions in other languages is a good thing. But I think it is a low priority one, since I find hard to imagine a user selecting a language which she does not understand (otherwise will be already in the short list) just because the article is of good quality. In any case, users normally speak 1-8 languages, so even in a relatively short list there is still room for other criteria. The way to access more We choose the ... so that the label could work across languages. So that you can go back to your language if you arrive by accident to a foreign Wikipedia (or you are an advanced user curious to check if web fonts were enabled in Javanese wikipedia). However, the visual execution needs some work still to make it more touch friendly among other things. Details on the language list UI The interactive prototype was created to communicate the main idea and most details are still lacking. Thanks for pointing layout and navigation problems. The layout of the list is one of the aspects that needs more work: currently we group the languages by script to help the user to recognise their familiar scripts, and the algorithm also makes some
Re: [Wikitech-l] Tutorial on Semantic MediaWiki in Russian
Le vendredi 19 avril 2013 à 21:02 +0300, Paul Selitskas a écrit : That is a nice starter guide! Thank you, Yury! I'll be definitely interested to have the english version. Well, to be honnest, I would prefer some magical recipe for Russian instant learning, but I doubt anyone can provide such a thing. ;) On Fri, Apr 19, 2013 at 7:35 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! In Semantic MediaWiki we have great but very long documentation. I've tried to write a small introduction to SMW. It's only in Russian now (I know that some amount of Russian MediaWikers are reading this mailing list), but I think to write something similar in English (maybe to IBM DeveloperWorks). http://habrahabr.ru/post/173877/ If you don't know Russian you can enjoy the pictures anyway ;) Cheers, - Yury Katkov, WikiVote ___ 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] Tutorial on Semantic MediaWiki in Russian
Any ideas where to publish the English version? I was quite surprised when I found out that there is no collective blog in english internet as our Habrahabr. I was thinking about IBM Developerworks but maybe they need something closer to the programming. Can I try to propose the article to http://blog.wikimedia.org/c/technology/ ? - Yury Katkov, WikiVote On Sat, Apr 20, 2013 at 4:11 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le vendredi 19 avril 2013 à 21:02 +0300, Paul Selitskas a écrit : That is a nice starter guide! Thank you, Yury! I'll be definitely interested to have the english version. Well, to be honnest, I would prefer some magical recipe for Russian instant learning, but I doubt anyone can provide such a thing. ;) On Fri, Apr 19, 2013 at 7:35 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! In Semantic MediaWiki we have great but very long documentation. I've tried to write a small introduction to SMW. It's only in Russian now (I know that some amount of Russian MediaWikers are reading this mailing list), but I think to write something similar in English (maybe to IBM DeveloperWorks). http://habrahabr.ru/post/173877/ If you don't know Russian you can enjoy the pictures anyway ;) Cheers, - Yury Katkov, WikiVote ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] No cascade protection on Mediawiki namespace
Right now the MediaWiki namespace is protected from editing. However, if you add a template to a Mediawiki message and the template is unprotected, any user could edit the message by editing the template, creating a backdoor. There is no option to cascade protect MediaWiki messages on wiki, and there is no function in the MediaWiki software to cascade protect an entire namespace. Should this be fixed? Techman224 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] No cascade protection on Mediawiki namespace
This sounds like an issue. If others agree, I could work on this. On Apr 20, 2013 1:09 AM, Techman224 techman...@techman224.ca wrote: Right now the MediaWiki namespace is protected from editing. However, if you add a template to a Mediawiki message and the template is unprotected, any user could edit the message by editing the template, creating a backdoor. There is no option to cascade protect MediaWiki messages on wiki, and there is no function in the MediaWiki software to cascade protect an entire namespace. Should this be fixed? Techman224 ___ 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] No cascade protection on Mediawiki namespace
Why not just protect the template when you add it? I think you may be over thinking this just a tad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
