User talk:GWicke

This page used the LiquidThreads extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.

OutputPage Microdata API

Latest comment: 13 years ago6 comments2 people in discussion

GWicke, I've been going over the idea for apis for adding global Microdata and RDFa data to a page. After thinking about it more I can't think of any value at all for an api that adds anything beyond one single page wide Microdata item.

The only value itemprops have in the <head> is for specifying things on a page wide itemscope, ie: http://schema.org/WebPage.
Anything other than that can be done inside the body.
Microdata doesn't have any way for two itemscopes to co-exist. So there is no way for any more than one itemscope to be inside the head. If there is any other page wide itemtype it can only work by completely replacing schema.org's WebPage type.
The reasoning for schema.org's WebPage being page-wide is both so that things like the name, image, description, etc... can be defined in the head as well as for the definition of in-body things like breadcrumbs, significant links, the primary image, etc... other itemtypes wouldn't have that same kind of value and don't have a reason to be page-wide inside the head. Daniel Friesen (Dantman) (talk) 08:28, 22 February 2012 (UTC)Reply

I agree- which is also why I wouldn't mind adding that itemtype statically in the skin.

I had a conversation with Ian Hickson about the missing multi-itemtype support on Monday. It does not seem to be easy to convince him of the benefits. A set of very concrete and well-presented use cases seems to be about the only thing that might move him to consider it. He also stated that Google et al would adapt their custom indexing to anything we do anyway.

RDFa handles the multiple-itemtype case well, and has the additional advantage of hooking into RDFS et al if needed. Might be something to consider for the parser DOM too, if we can't convince Hixie. The differences in DOM structure between the two are mostly about slightly different names and contents of attributes. Manu Sporny (the W3C RDFa-in-HTML5 WG chair) offered his support as well. GWicke (talk) 09:22, 22 February 2012 (UTC)Reply

My initial thought was to create an api that could create something like User:Dantman/Output Metadata/Example Output. An api that would let you define multiple Microdata items and anything beyond one global would be appended to the <body> so that it would be parsed. However then you're given the fact that WebPage also uses the body. So I thought of a hack that would make WebPage weighted heavier, ie: if WebPage was used as an itemtype the engine would implicitly make it the one on the body even if another extension inserted something else. But then where's the value in that, especially if another vocab does in fact have a good reason for the same. So it all fell apart.

Originally I was only adding itemprop="" for completion sake. It's something that <meta> supported and I was adding support for the property="" attribute.

But right now in fact I can't even find a good reason for it's actual use anywhere at all. The Google +1 button that suggests it's use actually parses OpenGraph data already. I doubt WebPage's name and description attributes give much value given they're already part of standard metadata. Heck WebPage doesn't even have a way to separate name and sitename like OpenGraph does. And I haven't quite figured out what the value of some of the itemprops that actually belong to WebPage are for. Hell, WebPage has a mainContentOfPage that's supposed to be usable to indicate the primary contents, but it uses a WebPageElement and most pages don't have types that fit into that at all.

So I'm with the thought of completely excluding Microdata support till someone comes up with a good hard use case they want to support, at which point we can go hardcode something in for it.

For skins like you think sounds like a good idea. In that case we should add another hook or two to make sure that skins are capable of tweaking the attributes for the <html> tag, etc...

----

I actually spent most of yesterday reading through RDFa and getting a full understanding of all the rules and properties of it. I actually kind of like it. Microdata still has it's own likeable taste, and RDFa can notably be hard to understand for general users, but still RDFa is pretty good.

If Google et-all are going to work around us, then perhaps in the cases where we do find something we want to do with Metadata on the global page we should try using RDFa even if the data is actually supposed to be Microdata.

((I wonder what Google would think if we started embedding RDFa data onto articles that let them parse out category information))

For RDFa support I haven't thought up the full API yet. However I did consider part of the Sub-API. What do you think of this class User:Dantman/Output Metadata/Namespace API? It's goal is to let us use XML/RDFa namespaces but do it in a clean format way that guarantees that we're not going to have two extensions ever collide with the same prefix for different namespaces. Daniel Friesen (Dantman) (talk) 17:45, 22 February 2012 (UTC)Reply

The need for such a class illustrates why microdata tries so hard to avoid XML namespaces ;) In general it looks quite useful to me, at least for the management of global prefixes defined on the html element.

An alternative would be to discourage manually defining / using prefixes, and simply use full URIs. For compression, we could either rely on gzip to do its thing or convert URIs to prefixed names for known (and/or globally defined) global prefixes. Gabriel Wicke (GWicke) (talk) 09:15, 29 February 2012 (UTC)Reply

Actually Microdata just wants to cater to the lowest common denominator. ;)

XML's namespaces aren't that bad. In fact this class is only useful on the global scope because we'd be shoving thing from multiple extensions into the head. Besides the narrow case of stuff being put into the head everywhere else it works fine without conflicts because even if the rest of the app is disconnected and could be using different namespaces all you do is define the namespaces you actually use locally.

The class really isn't even needed, it's only to avoid a extremely, extremely, extremely remote edge case which in all reality we will never ever run into. But it's a bug and it's fun to fix ;). Makes code cleaner too.

Full URIs would be a bad idea. One note property="" is a SafeCURIEorCURIEorIRI. Technically that means if you define a xmlns:http or prefix="http: ..." it could be evaluated as a CURIE instead of an IRI. But more importantly, OpenGraph is shit. OpenGraph even states "We've based the initial version of the protocol on RDFa". In other words, it's actually NOT RDFa. Besides the fact that OpenGraph ignores <link> and uses <meta> to define urls. And the fact that the way OpenGraph uses og:image and og:image:width and requires proper ordering of the properties is technically incompatible with RDFa if an implementation doesn't keep the sort order. Most OpenGraph implementations work by looping over <meta> elements and looking for property attributes starting with og:. And there doesn't seam to be anything on the OGP page to say they're wrong to do that. Facebook works fine even when you don't define an og: namespace, so I wonder what they're even doing to parse things. In other words, if we switch from og: to absolute uris, practically every OpenGraph using system will likely stop understanding data we output. Daniel Friesen (Dantman) (talk) 11:52, 29 February 2012 (UTC)Reply

I do not care very much about OpenGraph. RDFa should have not trouble with absolute URIs. Gabriel Wicke (GWicke) (talk) 11:58, 29 February 2012 (UTC)Reply

SPAM auf wikidev.net

Latest comment: 13 years ago2 comments2 people in discussion

Nur zur Information: Deine Website wikidev.net wird seit geraumer Zeit zugespamt. Nicht so toll, wenn man Infos für Mediawiki darauf sucht. 178.13.4.206 07:26, 7 April 2012 (UTC)Reply

Ja, ich weiß- aber danke für den Hinweis ;) Ein Frühjahrsputz ist definitiv nötig. Gabriel Wicke (GWicke) (talk) 07:52, 7 April 2012 (UTC)Reply

Normalization of wiki text

Latest comment: 12 years ago5 comments1 person in discussion

Hi!

Do you know if the normalization of the source code of the articles (by Parsoid/Visual Editor) would remove (add?) any line breaks of the kind described on w:Wikipedia:Don't use line breaks? Helder 12:01, 4 June 2012 (UTC)

You can try it at http://parsoid.wmflabs.org/, more specifically at http://parsoid.wmflabs.org/_rtform/. We basically try to preserve all line breaks from the source. I just fixed a bug in the handling of newlines in preformatted text, which will also go live after review. Gabriel Wicke (GWicke) (talk) 12:10, 4 June 2012 (UTC)Reply

Thanks for the info! Helder 12:16, 4 June 2012 (UTC)

I noticed it changes "[[link|text]]" to "[[Link|text]]". Is it aware of $wgCapitalLinks, which is used on wiktionaries?

Would it be possible to have the test service working also for non-English wikis? E.g.:

http://parsoid.wmflabs.org/_rt/pt:foobar

could get the text from

http://pt.wikipedia.org/wiki/Foobar

or we could have some select box to choose the wiki. Helder 12:57, 4 June 2012 (UTC)

http://parsoid.wmflabs.org/_rt/pt:Foo now returns the Portuguese article. All other Wikipedias should also be available. Localized syntax such as namespaces (media / images, categories) is not yet handled in Parsoid, so it won't render those properly in the HTML DOM for languages other than English. Gabriel Wicke (GWicke) (talk) 09:45, 5 June 2012 (UTC)Reply

Great! Thank you very much!

I noticed one more (small) thing: on of the headers says "Diff between original Wikitext (green) and round-tripped wikitext (red)" but the HTML is using <del> for the new text and <ins> for the old one. I think it would be more semantically correct if these were interchanged (because it is the old text that is being deleted, not the new one), and then red style should be in the <ins> and the green in the <del>. Helder 13:28, 6 June 2012 (UTC)

Good catch! I swapped the diff order and thus the markup, but kept the colors the same. The green text is the correct original, while the red one differs from it. Gabriel Wicke (GWicke) (talk) 14:06, 6 June 2012 (UTC)Reply

I noticed it changes the category sort order from

[[Categoria:Análise sintática (computação)| ]]

to

[[Categoria:Análise sintática (computação)|]]

Is this a known issue (e.g.: caused by what is described at Parsoid/Todo#Internal links, categories and images) or a new one?

What kind of thing should we watch for in case we want to report bugs? Helder 13:48, 6 June 2012 (UTC)

Here is one more problem(?):

<math>x = \left\{
   \ldots
 \right.</math>

is converted to

<math>x = \left\{
 </math>\ldots
 
 
 \right.

(this is a simplification of what I found at pt:Polinômio) Helder 13:51, 6 June 2012 (UTC)

Both cases are new to me, although I did some work on extra newlines yesterday. Thanks for the report!

For the first release this month we are mainly focused on round-tripping of basic formatting, headings, lists, tables and links. Reports in that area (as yours above) are most welcome. Round-tripping for other constructs (thumbs, templates etc) is not yet implemented, so it should be more efficient to ignore those for now. Gabriel Wicke (GWicke) (talk) 14:15, 6 June 2012 (UTC)Reply

Is there any announcement which we could translate to other languages asking for testers? I would like to advertise this on Portuguese Wikipedia's Village Pump (maybe it could be used the Global message delivery?). Helder 11:52, 9 June 2012 (UTC)

There is no announcement yet anywhere apart from some wikitext-l posts. There will be one for the testing release together with the visual editor later this month. Will let you know when it is ready. Gabriel Wicke (GWicke) (talk) 22:47, 12 June 2012 (UTC)Reply

parsoid.wmflabs.org

Latest comment: 12 years ago1 comment1 person in discussion

Hi!

Is it just me or http://parsoid.wmflabs.org is not working anymore since a few days ago? Helder 02:11, 7 July 2012 (UTC)

The service broke for some reason while I was away (preparing to move to SF). Just started it again, now looking for the reason why it went down. Thanks for the heads-up! Gabriel Wicke (GWicke) (talk) 08:24, 7 July 2012 (UTC)Reply

https

Latest comment: 11 years ago1 comment1 person in discussion

Hi!

Is it ok to change http://mediawiki.org/rdf/ to https://mediawiki.org/rdf/ on Parsoid/MediaWiki DOM spec? Helder 09:55, 4 September 2013 (UTC)

That should be fine, but we should also adjust the code to match at the same time. Gabriel Wicke (GWicke) (talk) 15:24, 4 September 2013 (UTC)Reply

Parsoid on distant server node.js

Latest comment: 11 years ago5 comments3 people in discussion

Hi,

I'm stucked on this problem. I installed Parsoid on my distant server (node.js 0.10.15) from gandi.net, but when i start my server, workers loads and when they are ready, they report this error (for all):

events.js:72
       throw er; // Unhandled 'error' event
             ^
Error: bind EADDRINUSE
   at errnoException (net.js:901:11)
   at net.js:1073:26
   at Object.1:1 (cluster.js:587:5)
   at handleResponse (cluster.js:171:41)
   at respond (cluster.js:192:5)
   at handleMessage (cluster.js:202:5)
   at process.EventEmitter.emit (events.js:117:20)
   at handleMessage (child_process.js:318:10)
   at child_process.js:392:7
   at process.handleConversion.net.Native.got (child_process.js:91:7)
worker 867 died (8), restarting.
- worker(912) ready

Thanks for followed answers. Meryl28 (talk) 09:13, 9 September 2013 (UTC)Reply

Some other service is using port 8000. This could be another Parsoid instance, or an unrelated service.

You can either stop that service, or change Parsoid's port by setting the VCAP_APP_PORT environment variable:

VCAP_APP_PORT=9000 node server.js Gabriel Wicke (GWicke) (talk) 16:36, 9 September 2013 (UTC)Reply

On gandi, i have a default server.js already using port 8080 (i set my parsoid server to 8080).

So that's probably this. But gandi's server allow me access only on port 8080.

I can't force ports usage.

On gandi's server, i have default directory, it's my root. In it, i have server.js by default. That server.js is ran automatically. VisualEditor catch this front-page's text and, when i save in VE, this text is saved in anyway.

I haven't rights before this directory, so how can i run my parsoid instance from this root ?

Sorry for imperfections in my english. Meryl28 (talk) 08:00, 10 September 2013 (UTC)Reply

You will need a free port to use by Parsoid. If your wiki is running on the same box, then that port does not even need to be accessible from the outside. If you can reach http://localhost:8000/ (assuming default port) from the wiki box, then you will be fine. Gabriel Wicke (GWicke) (talk) 15:23, 10 September 2013 (UTC)Reply

Just Log out completly and then try again...

It works for me 122.172.185.201 15:13, 30 October 2013 (UTC)Reply

Page metadata

Latest comment: 11 years ago2 comments2 people in discussion

In light of the roadmap and the work you're doing, should Requests for comment/Page metadata be closed as an issue that's been decided, or are there still some metadata topics we should invite the community to discuss? Leucosticte (talk) 04:11, 12 October 2013 (UTC)Reply

As a first step, we intend to separate page properties from content in HTML DOM. This requires little discussion with the wider community, as users don't normally interact with HTML directly. For wikitext users, nothing will change for now.

Removing page properties from the wikitext however will definitely require discussions. In templates, I expect them to stay as long as wikitext does. In the page itself we'll still need very good UIs for diffing and editing of these properties. We plan to work on diffing, and a page property edit UI is being developed as part of the VisualEditor. Right now this is still fairly far out though, so it is difficult to discuss specifics.

I think it makes most sense to just do the work that can make this an option. Once at least prototypes of the user experience are available we should be able to discuss specific options without too much hand waving. Gabriel Wicke (GWicke) (talk) 07:41, 15 October 2013 (UTC)Reply

Requests for comment/Allow styling in templates

Latest comment: 11 years ago1 comment1 person in discussion

Hi, Requests for comment/Allow styling in templates is being considered as one of the RFCs to be discussed at the RFC review on 2013-11-06 via IRC. You are receiving this notification because you edited or discussed this RFC. We hope to see you there. Qgil (talk) 00:43, 5 November 2013 (UTC)Reply

Parsoid and password-protected wikis

Latest comment: 11 years ago6 comments2 people in discussion

Hi,

regarding your change http://www.mediawiki.org/w/index.php?title=Parsoid/Troubleshooting&diff=0&oldid=797441 :

I think, my text (which you now have deleted) talking about the password-protected wiki is still relevant, because the Parsoid needs to know the password (this is my current thinking; I haven't tried it yet for my wikis). So, if there is a problem with the password, Parsoid and the Visiual Editor will not work.

And this should be mentioned as one of the possibilities on the Troubleshooting page. Wikinaut (talk) 06:24, 22 November 2013 (UTC)Reply

Currently parsoid just forwards the cookie header (if set) to the wiki. If you are using VisualEditor, see the relevant configuration options for cookie forwarding in the VE extension. Gabriel Wicke (GWicke) (talk) 06:26, 22 November 2013 (UTC)Reply

Thanks.

I changed the text on that page, but can you please adapt it a second time, so that it then will probably be perfect? Wikinaut (talk) 06:29, 22 November 2013 (UTC)Reply

I made it clear that no change on the Parsoid side is needed. All that is needed is to configure the VE extension properly. Gabriel Wicke (GWicke) (talk) 06:31, 22 November 2013 (UTC)Reply

Gabriel, I think, this change of Parsoid is really a big step forward. As soon as I have the time, I will try to deploy the latest version to all my protected wikis, some of them are using AuthPlugin in a Kerberos-authenticated intranet - where the VE/Parsoid currently could not be used.

I will report later, if it really works (I am confident, it will...)

-)) Wikinaut (talk) 06:43, 22 November 2013 (UTC)Reply

Great that it makes Parsoid more useful to you ;) In the foundation people were very happy when VE was enabled on a few internal wikis.

Note that when a cookie is set, we are sending no-cache headers for security reasons. In production most Parsoid output comes from the Parsoid Varnish caches, but private wikis are forced to be re-rendered for each request. Eventually we'll store HTML and do the access right checks at that layer. At that point private wikis will be fast too. Gabriel Wicke (GWicke) (talk) 06:49, 22 November 2013 (UTC)Reply

Stammtisch am 11. März im Walzwerk

Latest comment: 11 years ago2 comments2 people in discussion

Hallo Gabriel, unser nächster Stammtisch wird am 11. März im Walzwerk (Mission) stattfinden. Für die An- bzw. Abmeldung steht seit gestern die Seite Wikipedia:San Francisco zur Verfügung. Freue mich schon auf ein Wiedersehen :-) P.S. Bitte trag dich auch ein, wenn dir ein anderer Termin besser passen würde. Frank Schulenburg (talk) 23:10, 27 February 2014 (UTC)Reply

Danke, hab mich eingetragen. Bis dann! Gabriel Wicke (GWicke) (talk) 23:21, 27 February 2014 (UTC)Reply

Mathoid

Latest comment: 10 years ago3 comments2 people in discussion

I posted a question about Mathoid at Talk:Wikimedia Engineering/2014-15 Goals. Would you be able to answer there? Thanks in advance. Deltahedron (talk) 21:21, 25 July 2014 (UTC)Reply

Just replied there. Thanks for letting me know! Gabriel Wicke (GWicke) (talk) 23:32, 25 July 2014 (UTC)Reply

Thanks for the prompt response! Deltahedron (talk) 06:40, 26 July 2014 (UTC)Reply

How TAssembly limits the variables to the model

Latest comment: 10 years ago1 comment1 person in discussion

First I must says that TAssembly looks like a fantastic piece of work.

I don't follow however the code very well and so I was wondering how it limits the variable use to the model ones and refuse for example window global object. After looking more on the code it looks like the key function is rewriteExpression which prepend all access with c. (except when it is not a global member) I am right ? Xavier Combelle (talk) 18:03, 2 February 2015 (UTC)Reply

Please provide feedback on suggested improvements to the Code of Conduct

Latest comment: 9 years ago1 comment1 person in discussion

Thanks to everyone who’s helped work on the Code of Conduct so far.

People have brought up issues they feel were missed when working on "Unacceptable behavior" and "Report a problem". Consultants have also suggested changes in these same sections.

These are important sections, so please take a look at the proposed changes. I apologize that this feedback arrived later than planned, but I think this will create a better document.

If you prefer to give your opinion privately, feedback via e-mail is welcome at conduct-discussionwikimedia.org.

Thanks. Mattflaschen-WMF via MediaWiki message delivery (talk) 04:18, 24 February 2016 (UTC)Reply

Easy way to pull data view json to (web|wiki)pages

Latest comment: 9 years ago1 comment1 person in discussion

Hi GW. Hope that the world is looking somewhat rosier. You know that I am not the most competent in coding, and I am looking to know if there is a convenient means to convert json from the RESTbase / PageView API into viewable webpages for the wikis. Is there some little interpreter or something that can help the clueless administrator to bring good data to viewing on wiki to share with fellow clueless coders? Thanks for any direction that you can give? Thanks. — billinghurst sDrewth 06:09, 29 February 2016 (UTC)Reply