Re: [Wikitech-l] GRAPH extension is now live everywhere!
Hi, Yuri! I think will be reasonable to allow transclusion of graphs (or their parts, for example without text labels) from Commons. This will allow to share graphs between projects. Eugene. On Wed, May 6, 2015 at 5:51 AM, Yuri Astrakhan wrote: > Jon, is designed to support template parameter expansions, and I > found most convenient to place each graph into a separate template page. > > David, re VE - https://phabricator.wikimedia.org/T93585 > > On Wed, May 6, 2015 at 2:27 PM, David Gerard wrote: > >> Is there a facility to use this in VE? >> >> On 6 May 2015 at 12:25, Jon Robson wrote: >> > I think this is great but I'm still super super concerned about the >> support >> > for "Embedded directly with ". I'm concerned as if used this way >> we >> > risk making wikitext even more like code and more difficult for others to >> > edit. Also having it inside the page makes it really difficult to >> > extract/encourage remixing of the data... >> > >> > On Wed, May 6, 2015 at 4:32 AM, Brian Wolff wrote: >> > >> >> On 5/5/15, Yuri Astrakhan wrote: >> >> > Starting today, editors can use ** tag to include complex >> graphs >> >> and >> >> > maps inside articles. >> >> > >> >> > *Demo:* https://www.mediawiki.org/wiki/Extension:Graph/Demo >> >> > *Vega's demo:* >> >> http://trifacta.github.io/vega/editor/?spec=scatter_matrix >> >> > *Extension info:* https://www.mediawiki.org/wiki/Extension:Graph >> >> > *Vega's docs:* https://github.com/trifacta/vega/wiki >> >> > *Bug reports:* https://phabricator.wikimedia.org/ - project tag >> #graph >> >> > >> >> > Graph tag support template parameter expansion. There is also a >> Graphoid >> >> > service to convert graphs into images. Currently, Graphoid is used in >> >> case >> >> > the browser does not support modern JavaScript, but I plan to use it >> for >> >> > all anonymous users - downloading large JS code needed to render >> graphs >> >> is >> >> > significantly slower than showing an image. >> >> > >> >> > Potential future growth (developers needed!): >> >> > * Documentation and better tutorials >> >> > * Visualize as you type - show changes in graph while editing its code >> >> > * Visual Editor's plugin >> >> > * Animation < >> https://github.com/trifacta/vega/wiki/Interaction-Scenarios >> >> > >> >> > >> >> > Project history: Exactly one year ago, Dan Andreescu (milimetric) and >> Jon >> >> > Robson demoed Vega visualization grammar < >> >> https://trifacta.github.io/vega/> >> >> > usage in MediaWiki. The project stayed dormant for almost half a year, >> >> > until Zero team decided it was a good solution to do on-wiki graphs. >> The >> >> > project was rewritten, and gained many new features, such as template >> >> > parameters. Yet, doing graphs just for Zero portal seemed silly. Wider >> >> > audience meant that we now had to support older browsers, thus >> Graphoid >> >> > service was born. >> >> > >> >> > This project could not have happened without the help from Dan >> Andreescu, >> >> > Brion Vibber, Timo Tijhof, Chris Steipp, Max Semenik, Marko Obrovac, >> >> > Alexandros Kosiaris, Jon Robson, Gabriel Wicke, and others who have >> >> helped >> >> > me develop, test, instrument, and deploy Graph extension and Graphoid >> >> > service. I also would like to thank the Vega team for making this >> amazing >> >> > library. >> >> > >> >> > --Yurik >> >> > ___ >> >> > Wikitech-l mailing list >> >> > Wikitech-l@lists.wikimedia.org >> >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> >> >> >> >> Hmm cool. >> >> >> >> One of the interesting things, is you can use the API as a data >> >> source. For example, here is a pie graph of how images on commons >> >> needing categories are divided up >> >> >> >> >> https://commons.wikimedia.org/w/index.php?title=Commons:Sandbox&oldid=159978060 >> >> (One could even make that more general and have a template, which >> >> given a cat name, would give a pie graph of how the subcategories are >> >> divided in terms of number). >> >> >> >> --bawolff >> >> >> >> ___ >> >> Wikitech-l mailing list >> >> Wikitech-l@lists.wikimedia.org >> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> >> > >> > >> > >> > -- >> > Jon Robson >> > * http://jonrobson.me.uk >> > * https://www.facebook.com/jonrobson >> > * @rakugojon >> > ___ >> > 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 mailing list Wikitech-l@
Re: [Wikitech-l] Sharing mathematical and music notations across wikis
Hi, Gerard! On Fri, Mar 21, 2014 at 5:48 AM, Gerard Meijssen wrote: > Hoi > I do not understand what you expect of Wikidata... > Thanks >GerardM Wikidata allows to refer to media file. In this case: TeX of music score. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sharing mathematical and music notations across wikis
Hi, Micru! On Fri, Mar 21, 2014 at 6:13 AM, David Cuenca wrote: > Hi Eugene, > you already can upload scores to Commons and transcribe them on Wikisource > as agreed on this RFC > https://meta.wikimedia.org/wiki/Requests_for_comment/Musical_score_transcription_project_proposal My point is to share such transcribes between projects. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sharing mathematical and music notations across wikis
Hi! I think will be good idea to introduce support for files in TeX and ABC/Lilypond (Score extension) formats, so such files could be hosted on Commons. This will simplify maintenance of formulas and music across projects as well as allow to refer to mathematical and music notations from Wikidata. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Unification of inter-project links with Extension:RelatedSites
Hi! As of now Extension:RelatedSites is used on Wikivoyage only, but I think will be good idea to use this extension for inter-project links unification across other WMF projects. Currently different templates present these links in different fashion. This introduces interface inconsistency as well as require maintaining and usage of set of templates on various projects. Extension:RelatedSites need some care: * it should allow project names localization; * it should be able to extract links from Wikidata. Tools | Data item should be displayed by this extension for consistency with other projects. Eugene, ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ARM servers
Hi! I think will be good idea to try to get access to real hardware. For example, Boston (http://www.boston.co.uk) produces Calxeda-based servers and well as HP has experimental Calxeda and X-Gene based cartridges for Moonshot servers (http://www.hp.com/moonshot). Both provide remote access to own servers for trials. Eugene. On Mon, Jan 13, 2014 at 4:40 PM, Tim Starling wrote: > On 14/01/14 10:55, George Herbert wrote: >> On Mon, Jan 13, 2014 at 3:33 PM, Tim Starling wrote: >>> >>> In fact, it would slow down individual requests by a factor of 7, >>> judging by the benchmarks of Calxeda and Xeon CPUs at >>> >>> http://www.eembc.org/coremark/index.php >>> >>> So instead of a 10s parse time, you would have 70s. Obviously that's >>> not tolerable. >> >> >> Question - is that 10s linear CPU core time for a parse, or 10s of average >> response time given our workloads? > > Just an arbitrary number chosen to be within the range of CPU times > for slower articles. On average, it is much faster than that. > > For actual data, you could look at: > > http://tstarling.com/stuff/featured-parse-boxplot.png > >> If it is the linear one-core parse processing time, how much of that is >> dependencies on DB lookups and the like, externalities within the >> infrastructure rather than the straight-line CPU time needed for the parse >> itself? > > WikitextContent::getParserOutput() profiles at around 1.25s real and > 1.17s CPU. > > -- Tim Starling > > > ___ > 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] 3d Online Geometry Viewer
Hi! On Mon, Jan 13, 2014 at 10:47 AM, Inderpreet Singh wrote: > On Sat, Jan 11, 2014 at 5:28 AM, Brian Wolff wrote: >> Hi, >> >> Thanks for writing. Previous discussions aboit 3d have usually been about >> x3d and cml, but i think most people just want a 3d format supported, and >> dont care which one (to speak from a wikimedia as opposed to a mediawiki >> prespective). > > Currently we have a support for .g (BRL-CAD's binary file format) > files, but BRL-CAD has a long list of supported formats so anything > that BRL-CAD can import will be supported. BRL-CAD can export files as > X3D but it cannot import them yet :( . The file formats that BRL-CAD > can import are ASCII, AutoCad DXF, Elysium Neutral Facetted, EUCLID, > FASTGEN, IGES, Jack, NASTRAN, STL, TANKILL, Unigraphics and Viewpoint > which can then be internally converted to .g file and exported to .obj > for 3D online geometry viewer. I think will be good idea to investigate, if there open 3D formats, i. e. non-proprietary and not covered by patents. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ARM servers
Hi! ARM servers is definitely worth to look at, but please be aware that technology is not mainstream and sad things may happens: http://calxeda.com (one of exhibitors of ARM TechCon). OS support if not mature yet, especially for ARMv8 (64 bit). Eugene. On Sun, Jan 12, 2014 at 1:05 AM, James Salsman wrote: > Nicolas Charbonnier's "Latest ARM Server solutions booths tour" may be > of some interest for those of you interested in low power server > hardware: > > http://armdevices.net/2013/12/30/latest-arm-server-solutions-booths-tour/ > > Mitac isn't represented there, but he did an interview of them a year > and a half ago: > > http://armdevices.net/2012/06/07/mitac-gfx-arm-server/ > > ___ > 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] Localizing site names displayed RelatedSites extension
Hi! How site names displayed by RelatedSites extension could be localized? For example, such links are heavily used in Wikivoyage, but only section header in toolbox is localized and English project names are used for links. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Redirects from Commons to wikimediafoundation
Hi! I experienced weird problem today when accessing Commons (addresses like https://commons.wikimedia.org/wiki/Special:Watchlist and http://commopns.wikimedia.org/wiki/Category:Yuri_Gagarin): I was redirected to same pages on http://wikimediafoundation.org. 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
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 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] Problems with file deletion on Commons
Hi! I'd like to bring to attention of developers and system administrators problems with file deletion on Commons: http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Daily_DR_issue Sorry, if it's known issue, but it persist for several days and definitely affects administrators job. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Missing project ideas for GSOC
Hi!
I think will be good idea to direct some of Google Summer of Code
participants energy to help Wikidata which misses many must-be
features. Some of them like support for projects other then Wikipedia
is postponed to next years, but something tells me that it may be
clone of existing functionality in most cases except one-to-multiple
links in Wikisource :-)
Eugene.
On Wed, Mar 20, 2013 at 4:43 PM, Quim Gil wrote:
> It's time to start defining what we want our Google Summer of Code to be all
> about. Let's look at the ideas we are proposing to potential students:
>
> https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
>
> Many of the ideas listed there are too generic ("Write an extension"),
> improvements of existing features ("Improve Extension:CSS") or
> work-in-progress tasks ("Fix Parsoid bugs"). Many others are not directly
> related with development, and therefore not suitable either for GSOC.
>
> After this filtering, we seem to be left with:
>
> * Article evolution playback tool idea
> * An easy way to share wiki content on social media services
> * Write an extension to support XML Sitemaps without using command line
> * Extension:OEmbedProvider
> * Add support for x3d 3D files to MediaWiki
> * Allow smoother and easier Wikimedia Commons pictures discovery
> * Build an interwiki notifications framework and implement it for
> InstantCommons
> * Automatic category redirects
>
> (If you think your project should also be considered here please speak up!)
>
> Most of these projects seem to be extension (and PHP?) centric. Can we have
> more diversity? Maybe gadgets and templates are too simple for a GSOC
> project? What about the mobile front? Do we have skin development projects
> that could make it here? Anything in the DevOps area? Anything the MediaWiki
> core maintainers would like to see happening?
>
> It would be also nice to have more candidates benefiting specific Wikimedia
> projects. Beyond Wikipedia, we have several proposals related to Commons.
> Wikidata seems to be joining soon. What else? Could this be a chance to help
> Wiktionary, Wikibooks or any other project with specific needs craving for
> tech attention?
>
> Also to the many students that have already showed their interest: feel free
> pushing your project ideas now!
>
> --
> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Periodic updates from bits.wikimedia.org
Hi, Tim! Thank you for suggestion! I installed LiveHTTPHeaders and sent two captures to Krinkle. Probably will need to do more of them. Eugene. On Thu, Aug 9, 2012 at 9:13 PM, Tim Starling wrote: > There's an extension called LiveHTTPHeaders which allows the relevant > request information to be captured and saved to a file. > > http://livehttpheaders.mozdev.org/ > > Open it from the tools menu, then do the things that are slow while > it's opened, then click "save all" and save it to a file. Don't post > the file publically, since it will contain your login cookies, but you > can send it to Krinkle as an email attachment, if he wants it. > > -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Periodic updates from bits.wikimedia.org
Hi, Krinkle! I'm very sorry for beginner question, but how could get such log in Firefox 14? Is some extension available which could dump all pages with timestamps downloaded to view particular page? Or may be Firefox could do this itself? Eugene. On Thu, Aug 9, 2012 at 7:59 AM, Krinkle wrote: > On Aug 9, 2012, at 4:49 PM, Eugene Zelenko wrote: > >> Hi! >> >> I noticed that content from bits.wikimedia.org (including WikiEditor) >> is updated quite regularly - ~ every 20 minutes on Commons. >> >> Such behavior is definitely creates problem for users with slow >> connections or with payed data traffic. >> >> Are JavaScript/CCS are really updated so often? >> >> Eugene. >> > > Can you elaborate a bit? (urls, timestamps, http headers, ..) > > -- Krinkle > > ___ > 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] Periodic updates from bits.wikimedia.org
Hi! I noticed that content from bits.wikimedia.org (including WikiEditor) is updated quite regularly - ~ every 20 minutes on Commons. Such behavior is definitely creates problem for users with slow connections or with payed data traffic. Are JavaScript/CCS are really updated so often? Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New preferences system
Hi! On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett wrote: > The advantage of this clear separation is that writing an API module > is very simple, and it can be called internally, too! I think will be good idea to use API internally (not only have possibility to call), as result code will have more testing and coverage. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You too can clean out the tons of database Default Messages
Hi! I asked similar question week ago. Can anybody from Wikimedia stuff answer this question? Eugene. PS We have new sysadmin there. May be it's good task to start? On Tue, Mar 24, 2009 at 4:34 AM, Andrew Garrett wrote: > On Tue, Mar 24, 2009 at 10:02 PM, wrote: >> I don't know why the design decision was made to just leave those >> Mediawiki: namespace items sitting in the archive and text tables. But > > Just run update.php. It does all that crap for you. > > -- > Andrew Garrett > > ___ > 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] Running deleteDefaultMessages.php on WMF wikis
Hi! We need to clean up old MediaWiki messages translations on be-x-old Wikipedia. deleteDefaultMessages.php looks as perfect candidate for this job. However last changes from MediaWiki_default were made in 2007. Is this code still functional? If so, I think will be good idea to run it on all WMF wikis, especially those which had long history of translation of MediaWiki messages (before translatewiki.net). Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Summer of Code 2009
Hi! I noticed that various free and open source software project started preparations for Google Summer of Code 2009, so I created http://www.mediawiki.org/wiki/Summer_of_Code_2009. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Interwiki conflicts
Hi!
See http://ru.wikipedia.org/wiki/User:VolkovBot/conflicts for list of
conflicts. VolkovBot is pretty active, so list should be more or less
comprehensive.
Eugene.
On Tue, Jan 6, 2009 at 1:52 AM, Lars Aronsson wrote:
>
> I just recently started to play with interwiki.py (Pywikipedia bot
> framework) for propagating interwiki links. My interest comes
> from organizing the category tree, so I'm focusing on interwiki
> links between categories. Interwiki bots normally run in
> autonomous mode, but this means they give up on complicated cases.
>
> If I run this script under manual supervision, without the
> "-autonomous" option, it stops and asks me how to resolve each
> conflict. This happens ever so often. I have now (manually)
> sorted out the interwiki links between all languages of
> Category:Knowledge, which was intertwined with Category:Science,
> and Category:Austrian writers which was mixed up with
> Category:Austrian literature. Such mistakes easily happen, of
> course. Who can spot errors in all these languages?
>
> Many languages had interwiki links from their category for
> Austrian writers to the Japanese category for Austrian literature.
> I'm not sure exactly when or where this error originated. But on
> June 19, 2007, the English and Spanish Wikipedia's interwiki link
> to Japanese changed from Austrian novelists to Austrian
> literature, i.e. from one error to another. Ten days later, this
> link was copied to the Dutch Wikipedia. The error was corrected on
> en.wikipedia on October 1, 2007, but remained on other languages.
> Yes, that's 15 months ago.
>
> The circular interwiki link structure from en:Category:Austrian
> writers to es:Categoría:Escritores de Austria to ja:... and back
> to en:Category:Austrian literature is such a conflict that makes
> interwiki.py give up when it runs in autonomous mode.
>
> Thus, corrections (as on October 1) do not propagate. Instead a
> report about the conflict is given in a logfile, but apparently
> nobody had fixed this problem in the last 15 monhts. This
> conflict also blocked new interwiki links from propagating.
>
> After I cleared up the mess, 21 new interwiki links were added to
> the category on the Russian Wikipedia (one where I have a bot
> flag). That means 21 languages of Wikipedia had created
> categories (or announced them to the interwiki system) for
> Austrian writers in the last 15 months, and they all added their
> interwiki link to the English Wikipedia. But these additions did
> not propagate because of the conflict.
>
> So, my question:
>
> Has anybody mapped exactly how many such interwiki conflicts we
> have? Or how many interwiki sets do we have without conflicts?
> Could/should someone make a list of current conflicts and try to
> rank them by importance, so we can get started in fixing them?
>
> In the longer term, we need to redesign the interwiki links into a
> centralized system, that can be maintained. I think the way to do
> this is to use Wikimedia Commons. Instead of copying all the
> interwiki links to every language of Wikipedia, it should be
> enough to add {{commons|Category:Writers from Austria}}, and the
> rest should happen automatically.
>
>
>
> --
> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some Ideas About Technical Stuff/Community Relations Improvements
Hi! On Thu, Dec 11, 2008 at 1:49 PM, Brion Vibber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 >> 2) Why new translations are not propagated to project X > > Translations are propagated to all our sites along with all other > software updates. It known, but don't explain cause of problem :-) Something stops or will stop deployment of new versions. So will be good idea to notify outside world a priori. At least TranslateWiki maintainers will be able to answer such questions :-) >> I think will be good idea to introduce some kind of technical stuff >> reporting and future planning (may be located on WMF site). It'll >> provide approximate answer for question 1; explain clearly situation >> with 2 (like "rXYZ introduced database scheme changes, currently >> updating WMF servers"). This will also highlight and communicate >> priorities to general public. > > This is pretty much what I try to do (not always as successfully as I > plan ;) on my blog: > > http://leuksman.com/log/ > > of which wiki-related posts are replicated on the Planet Wikimedia > aggregator: > > http://en.planet.wikimedia.org/ I don't think that blog is right place for such announcement. Especially Planet where technical issues will be mixed with non-technical ones. I think something more predictable and permanent like WMF wiki will do job better. > - -- brion > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAklBitkACgkQwRnhpk1wk4448gCgy4FeI18NP93jAmO+exRErNiT > sxUAoNmkuhitFP1YC3wPPJcci6pCQNAr > =qRwx > -END PGP SIGNATURE- Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Some Ideas About Technical Stuff/Community Relations Improvements
Hi! There are many signs of miscommunications between technical side of WMF operations and outside worlds (users, administrators, external projects): periodical rattling on Planet Wikimedia, frustrations on TranslateWiki, almost impermanently growing number of bug reports in Bugzilla. Typical example may include: 1) There is approved project X which still not created for Y days 2) Why new translations are not propagated to project X 3) Bug reports with opened years ago with several duplications Definitely technical stuff members are limited resource. And even trivial fixes or problems may took much more time then expected. Code changes reviewing require efforts. But outside world don't know what is going on and could only make uneducated guesses and in best case scenario perceive technical stuff as black box I think will be good idea to introduce some kind of technical stuff reporting and future planning (may be located on WMF site). It'll provide approximate answer for question 1; explain clearly situation with 2 (like "rXYZ introduced database scheme changes, currently updating WMF servers"). This will also highlight and communicate priorities to general public. This is not about control over developers but about development process transparency, which I believe, will improve understanding and appreciation of job done from outside. Think how CodeReview improve transparency of MediaWiki code base maintaining. Also development road map for next quarter/year may be considered. Possible solution for problem 3: * WMF may consider to allocate some part of development budget to outside developers. It may be in form of bug fixing bounties, gifts or sponsoring travel/accommodation for participation in Wikimania/MediaWiki developers conference. * Advertisement of "Google Summer of Code" jobs on WMF projects. Eugene. PS Disclaimers: I write weekly reports on work and don't think is most interesting part of it. I don't believe that reports are best reflection of working process. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bring your language to Commons
Hi! Gender was used as feature example similar to extracting user-preferred language. Sure, for Commons user-preferred language is much more critical since it'll exclude admins guess game when using templates on particular user talk page. I think categories translation and their usage in search will greatly improve value of Commons for non-English speakers. Eugene. On Tue, Dec 9, 2008 at 6:17 AM, Aryeh Gregor <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 2:42 AM, Gerard Meijssen > <[EMAIL PROTECTED]> wrote: >> Hoi, >> When we are to support genders or other personal aspect that can be >> reflected in the user interface, we can ask everyone for this information. >> Dependent on the answer people will be treated as per the provided >> information in those languages where gender makes a difference. >> >> Until the user preferences allow you to enter this information, it does not >> make sense to change the Internationalisation and the Localisation of the >> many languages that are supported in Betawiki. > > Obviously not. First the feature would need to be implemented, > including the user preference. This would probably include at least > one language being converted to use the system (maybe partially) as a > test case. Then the feature would be rolled out and translators would > be advised to implement it for their language if appropriate. > >> In the mean time there are >> many other issues that deal with Internationalisation that need to be >> solved. These include issues with RtL support, anyway it is a long list in >> Bugzilla. > > Are you suggesting that these other issues should be higher-priority > than genders? If so, why? > > ___ > 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] Bring your language to Commons
Hi! On Mon, Dec 8, 2008 at 9:55 AM, Brion Vibber <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eugene Zelenko wrote: >> How about demanding from foundation to allocate some part of latest >> usability improvement grant/resources >> (http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers) >> to solve at some of Commons problems? > > We probably won't get to much Commons-specific stuff in there, but we'll > see what sub-projects come up. Will be good idea to find old e-mail to wikitech-l from Brianna Laugher with Commons requirements since most of the requests still not implemented :-( For example, unsupported categories translation already used for Commons bad publicity on Russian Wikipedia. >> As for user language: see comments in similar request about user's >> gender (https://bugzilla.wikimedia.org/show_bug.cgi?id=13040), which >> also affect quality of MediaWiki localizations. > > Will social gender (often, but not always aligned with biological sex) > always track with grammatical gender? I hope so :-) > What are the cascading implications of user gender on localization > (adjective agreement in Romance languages, verb agreement in Semitic > languages) and what technical requirements would be imposed? Messages should be similar to GRAMMAR (for example GENDER). So sentences such as "User uploaded" could be more correctly translated as "Участник загрузил/Участница загрузила" on Russian or "Удзельнік загрузіў/Удзельніца загрузіла" on Belarusian. Same thing for Polish/Ukrainian and most likely for other Slavic languages. Gender settings could be also used in Babel extension and user boxes (currently uses parameters for this purpose). > - -- brion > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkk9X4EACgkQwRnhpk1wk44/AACgu3otzh0dqTkIZRi/W5VGbPfn > 9sIAmwbir/irI6iViQHWAZ9GgrSdVckM > =GE4z > -END PGP SIGNATURE- > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bring your language to Commons
Hi!
How about demanding from foundation to allocate some part of latest
usability improvement grant/resources
(http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers)
to solve at some of Commons problems?
As for user language: see comments in similar request about user's
gender (https://bugzilla.wikimedia.org/show_bug.cgi?id=13040), which
also affect quality of MediaWiki localizations.
Eugene.
On Sat, Dec 6, 2008 at 8:49 AM, Lars Aronsson <[EMAIL PROTECTED]> wrote:
>
> New user accounts on Wikimedia Commons automatically get a
> greeting from [[User:Wikimedia Commons Welcome]]. However, this
> greeting is in English and not all users speak English. At the
> top of the message there is a list of links to translations in
> other languages, but I think there is a better way.
>
> Since most new user accounts on Commons (about two thirds) are
> created by SUL, and arrive through a link that specifies the
> uselang= parameter, wouldn't it be very easy to set the user
> preference for user interface language from the uselang parameter
> when the account is created by SUL?
>
> The greeting template (and other templates, such as deletion
> requests) could then access the user's interface language setting
> through a {{USELANG}} magic word, and present the corresponding
> translation.
>
> This way, new Swedish speaking users (who typically arrive from
> the Swedish Wikipedia, one that doesn't allow local uploads) could
> be guided to the Swedish language village pump and find a
> community there.
>
>
> --
> Lars Aronsson ([EMAIL PROTECTED])
> Aronsson Datateknik - http://aronsson.se
>
> ___
> 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 Chemical Markup Language
Hi! On Fri, Nov 28, 2008 at 9:50 AM, Aryeh Gregor <[EMAIL PROTECTED]> wrote: > On Fri, Nov 28, 2008 at 12:45 PM, Eugene Zelenko > <[EMAIL PROTECTED]> wrote: >> Not yet. Is it precondition? :-) > > You should file a bug on Bugzilla to allow a central place for > discussion and reference, yes. Then you can lay out everything in the > bug report and just point people to it when asking for review. I'm > not aware offhand of any extensions not written by core devs that ever > got reviewed and enabled without a bug report filed, although I'm sure > it's happened. > > Make sure there's not already a bug open for it, though. Done. See https://bugzilla.wikimedia.org/show_bug.cgi?id=16491. > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Support for Chemical Markup Language
Hi! On Fri, Nov 28, 2008 at 9:37 AM, Aryeh Gregor <[EMAIL PROTECTED]> wrote: > On Fri, Nov 28, 2008 at 11:13 AM, Eugene Zelenko > <[EMAIL PROTECTED]> wrote: >> Hi! >> >> We are discussing on Commons list >> (http://lists.wikimedia.org/pipermail/commons-l/2008-November/004338.html) >> possible support for Chemical Markup Language >> (http://cml.sourceforge.net) and Jmol viewer >> (http://jmol.sourceforge.net). >> >> Extension for MediaWiki is already implemented >> (http://wiki.jmol.org/index.php/MediaWiki). However it was done for >> 1.12 and some security concerns exists. Will be great if somebody will >> review extension code and adapt it to current MediaWiki state if >> necessary. > > Is there a bug open? Not yet. Is it precondition? :-) > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Support for Chemical Markup Language
Hi! We are discussing on Commons list (http://lists.wikimedia.org/pipermail/commons-l/2008-November/004338.html) possible support for Chemical Markup Language (http://cml.sourceforge.net) and Jmol viewer (http://jmol.sourceforge.net). Extension for MediaWiki is already implemented (http://wiki.jmol.org/index.php/MediaWiki). However it was done for 1.12 and some security concerns exists. Will be great if somebody will review extension code and adapt it to current MediaWiki state if necessary. Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
