cscott added a parent task: T365746: Deploy mni-Beng language converter on
mniwiki.
TASK DETAIL
https://phabricator.wikimedia.org/T313883
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: cscott
Cc: Nokib_Sarkar, Nikki, Lydia_Pintscher, Aklapper
cscott added a comment.
Yeah, and if T114424 <https://phabricator.wikimedia.org/T114424> were to be
resurrected, it could/should use ParserOutput::setExtensionData, since all the
code paths described have just parsed the banner template and thus have the
ParserOutput available. Pag
cscott added a comment.
Rather than page properties, which are stored and indexed in a separate
database table, probably `ParserOutput::setExtensionData()` would be sufficient
for this use case.
TASK DETAIL
https://phabricator.wikimedia.org/T110843
EMAIL PREFERENCES
https
cscott renamed this task from "WikidataPageBannder doesn" to
"WikidataPageBannder doesn't seem to use wpb_banner wpb_banner_focus_x or
wpb_banner_focus_y page properties".
cscott claimed this task.
cscott added a project: Wikidata-Page-Banner.
cscott updated the task descr
cscott added a comment.
This dynamic property is causing spurious failures in phan as well, when phan
randomly "gets smart enough" to notice that the Title class doesn't actually
have a property named `wikibasePushedDeleteToRepo`. See
https://integration.wikimedia.org/ci/job/m
cscott added subscribers: Lucas_Werkmeister_WMDE, Jdlrobson, Lydia_Pintscher.
cscott added a comment.
From chat with WMDE:
@Lucas_Werkmeister_WMDE:
> I think {{SHORTDESC:}} (literally, i.e. with empty argument) could work,
something like this:
>
> - the magic word wo
cscott added a comment.
In T112426#1981741 <https://phabricator.wikimedia.org/T112426#1981741>,
@Amire80 wrote:
> Mmmm... any update about this? This breaks some ContentTranslation features
(such as T112285 <https://phabricator.wikimedia.org/T112285>), and delays the
r
cscott added a comment.
Deployed today to group2, and looks correct to me on enwikivoyage. Verified
that the `lang` and `dir` tags appear to be correct if you're using a
non-default user language as well.
Thanks for your help on this, @Jdlrobson!
TASK DETAIL
https
cscott added a comment.
A number of recent changes have been made which may have magically fixed this:
a) Parsoid gained the ContentMetadataCollector interface, implemented by
ParserOutput. So extensions which register 'out of band' data (ignored by
Parsoid) ought to have that data passed
cscott added a comment.
My only caution is that using strings to represent languages can be quite
error-prone, given that there are different "string codes" floating around for
the same language. In an ideal world, I'd say you should create a light-weight
language object in lu
cscott added a comment.
I *believe* the impact would be that the "horizontal table of contents" would
disappear from the page banner on wikivoyage, and of course they are
suppressing the 'normal' ToC so effectively no ToC on wikivoyage until this is
fixed. I don't know how that
cscott added a comment.
T105520 <https://phabricator.wikimedia.org/T105520> (with patch) would
provide the ability to customize the class and id of the TOC, which is one part
of what WikidataPageBanner is doing.
One solution here would be to explictly pass in the TOC in wi
cscott created this task.
cscott added a project: Wikidata-Page-Banner.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
See T93106: GSoC proposal for Wikivoyage PageBanner extension
<https://phabricator.wikimedia.org/T93106> for background on WikidataPage
cscott added a comment.
This is a very cool bug number.
TASK DETAIL
https://phabricator.wikimedia.org/T314159
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: cscott
Cc: cscott, Manuel, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot
cscott added a parent task: T308487: Article content (in the "content
language") often has user-interface elements ("in the UX language") mixed in.
TASK DETAIL
https://phabricator.wikimedia.org/T109705
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/pa
cscott created this task.
cscott added projects: MediaWiki-Parser, Patch-For-Review, Parsoid,
MediaWiki-extensions-WikibaseClient.
Restricted Application removed a project: Patch-For-Review.
TASK DESCRIPTION
As evidenced in SidebarHookHandlerTest, wikibase uses ::setExtensionData
cscott added a comment.
In any case, apart from my general griping, this is the actual issue:
In T298509#7609799 <https://phabricator.wikimedia.org/T298509#7609799>,
@cscott wrote:
> I don't know how DonationInterface and Wikibase are using this hook, but
Parsoid's use
cscott added a comment.
In T298509#7633961 <https://phabricator.wikimedia.org/T298509#7633961>,
@kostajh wrote:
> `composer phpunit:unit` will run unit (not integration) tests for core and
all skins/extensions, regardless of whether they're enabled, but those tests
d
cscott added a comment.
I don't know how DonationInterface and Wikibase are using this hook, but
Parsoid's use is pretty subtle and not obviously easily replaced: Parsoid is
*both* a library *and* and extension, and we need to be able to squirrel away
Parsoid's "standalone"
cscott added a comment.
There's an upstream PR for PHP: https://github.com/php/php-src/pull/7782
TASK DETAIL
https://phabricator.wikimedia.org/T268456
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lucas_Werkmeister_WMDE, cscott
Cc: Addshore
cscott added a comment.
(Also, just sayin': this would have been caught by CI if
`ShortDescHandler::doHandle()` were covered by any tests...)
TASK DETAIL
https://phabricator.wikimedia.org/T293860
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
cscott added a comment.
In T293860#7443715 <https://phabricator.wikimedia.org/T293860#7443715>,
@Lucas_Werkmeister_WMDE wrote:
> Okay, maybe not “easily”, given that `OutputPage` has similar methods that
weren’t renamed, and in the codesearch context it’s not immediatel
cscott added a comment.
I'll look at the code, the idea seems reasonable. We could also file a bug
upstream to see if PHP will add a bignum or string interface. Could also check
libicu to see what types they are supporting (maybe the fault is just in the
PHP wrapper).
Worth noting
cscott created this task.
cscott added projects: Parsoid, MediaWiki-extensions-WikibaseClient.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
The parser tests framework has a four-phase setup when running parsertests:
1
cscott added a comment.
Any chance this is going to be taken up again?
For Parsoid purposes, the interwiki mapping needs to be bidirectional -- that
is, we need to be able not just to go from `enwiki:$1` to
`//en.wikipedia.org/wiki/$1` but also given a URL
`https://en.wkipedia.org/wiki
cscott added a comment.
Yeah, IIRC Wikidata's namespaces are set up "oddly" with respect to other WMF
wikis, so this is probably a case where Parsoid is not carefully following the
siteinfo for the wiki.
TASK DETAIL
https://phabricator.wikimedia.org/T228616
EMAIL PREFERENC
cscott added a comment.
T249535 <https://phabricator.wikimedia.org/T249535> seems not related. More
likely the cause: the changes associated with
4d11e15ed098a0658719687557bb899c7cbf3711
<https://phabricator.wikimedia.org/rOMWC4d11e15ed098a0658719687557bb899c7cbf3711>
TASK DE
cscott added a comment.
This would be a content handler for whatever contentmodel type wikidata is
using for the Q42 pages.
Parsoid has a handler for the JSON contentmodel which lays it out as a table;
you could look at that as a basis.
TASK DETAIL
https://phabricator.wikimedia.org
cscott added a comment.
(And I agree with @Tgr's response to @Lydia_Pintscher that this issue isn't
directly related to MCR. In my mind it is about what "output types" and "input
types" are available for templates/extensions during preprocessing. Currently
extensions c
cscott added a comment.
FWIW, in T196440#5341715 <https://phabricator.wikimedia.org/T196440#5341715>
I moot around the idea of a specialized "arglist" data type to be returned by a
template, to make certain argument-list manipulations easier/more robust. I
think this
cscott added a comment.
Seems like we should probably make a plan to proactively manage Unicode
transitions on our three platforms (browsers, PHP, server-side JS).
TASK DETAIL
https://phabricator.wikimedia.org/T208139
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
cscott added a comment.
Yep, most likely related. @arlolra will probably write you a patch once he
wakes up/gets online this am, but if you're impatient just removing the
newlines from the indicated places in parserTests.txt will get you going again.
TASK DETAIL
https
cscott added a comment.
Seems to be fixed. Watching builds of https://gerrit.wikimedia.org/r/464096
https://gerrit.wikimedia.org/r/497471 and https://gerrit.wikimedia.org/r/497320
to confirm.
TASK DETAIL
https://phabricator.wikimedia.org/T218702
EMAIL PREFERENCES
https
cscott added a comment.
See
https://gerrit.wikimedia.org/r/#/q/topic:trail+(status:open+OR+status:merged)
for the set of patches merged; scribunto probably needs a patch somewhat like
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ParserFunctions/+/494939/
TASK DETAIL
https
cscott added a comment.
Yeah, we should just fix the scributo tests, not revert patches. This was a
set of 9 or so dependent patches to merge, unrolling would be quite a chore,
and the scribunto fix should just be to remove some trailing newlines from the
parser tests
TASK DETAIL
cscott added a comment.
There are a few patches which have actually (apparently) passes this test and
gotten merged, eg https://gerrit.wikimedia.org/r/496080
TASK DETAIL
https://phabricator.wikimedia.org/T218378
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
cscott added a comment.
OK, two patches to fix the issue: belt and suspenders. Both of them are potential candidates for cherry-picking to 1.32, but let's get them merged on 1.33 first.TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings
cscott added a comment.
Ah, ok, thanks! That means I don't have to worry about this being an "unbreak now" sort of bug.
https://gerrit.wikimedia.org/r/468589 is a stopgap at fixing the issue, but there's a deeper confusion between BCP 47 and mediawiki internal codes which is causing
cscott added a comment.
Agh. WikiBase/lib/includes/LanguageWithConversion.php contains code cut-and-pasted from mediawiki-core. Anyone want to guess the odds that it wasn't updated when the code from core was updated?TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps
cscott added a comment.
Ok, merged T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException" into this one, because the stack trace is pretty much identical:
This bug T207433, request ID W8llMwpAMEsAACb4rOcW:
0 /srv/mediawiki/php-1.32.0-wmf.26/extension
cscott closed this task as a duplicate of T207433: uselang=sr-cyrl causes fatal exception of type "MWException".
TASK DETAILhttps://phabricator.wikimedia.org/T207447EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Nikerabbit, Aklapp
cscott merged a task: T207447: uselang=zh-hant-hk causes fatal exception of type "BadMethodCallException".
TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Nikerabbit, cscott, Aklappe
cscott added a comment.
Also -- sr-cyrl, zh-hans-tw, etc are not actually the mediawiki-internal names for these languages. https://gerrit.wikimedia.org/r/460039 would have added support for using the standard names, but I'm a little bit surprised that anything is generating links to these &quo
cscott added a comment.
Given that uselang processing is involved, perhaps Ica89d9547c58967747ab0fa15d4e83be5378796d is the proximate cause. Can we get a stack trace for that exception?TASK DETAILhttps://phabricator.wikimedia.org/T207433EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings
cscott added a comment.
Any updates on this task? As I said, I'd like to write Scribunto/JS using v8js at some point. If v8js would be helpful to wikibase, perhaps we can pool efforts.TASK DETAILhttps://phabricator.wikimedia.org/T197690EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings
cscott added a comment.
We only emit the "@graph" form in purtle if the API is used to annotate more than a single entity: https://github.com/wikimedia/purtle/blob/master/src/JsonLdRdfWriter.php#L37
So you're not really asking for a change in the JSON-LD, you're asking for wikidata to
cscott added a comment.
...and adding .jsonld at the end should also work, right?TASK DETAILhttps://phabricator.wikimedia.org/T122711EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: cscott, Lucas_Werkmeister_WMDE, thiemowmde, Multichill, hoo
cscott added a comment.
I also worked on proper JSON+LD statements in T44063: [Epic] Provide a plain linked data interface for accessing entities and T164655: Store and serve annotations in W3C standard format. FWIW, with https://gerrit.wikimedia.org/r/384050 you get the following JSONLD for Q100
cscott closed this task as "Resolved".cscott claimed this task.cscott added a comment.
Well, I rebased my two patches on top of @Legoktm's patch and the builds are passing now, so I'll call that fixed.TASK DETAILhttps://phabricator.wikimedia.org/T206738EMAIL PREFER
cscott added a comment.
Ah.TASK DETAILhttps://phabricator.wikimedia.org/T206738EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: gerritbot, Legoktm, cscott, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci
cscott created this task.cscott added projects: Jenkins, Wikimedia-production-error, Wikidata.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONSee for example:
https://gerrit.wikimedia.org/r/462297 https://integration.wikimedia.org/ci/job/mwext-php70-phan-docker/14812/console
cscott updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...* `mo` does not exist, it should be `ro-md` (or `ro-cyrl`)Cyrl-md`: T18889...TASK DETAILhttps://phabricator.wikimedia.org/T125073EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
cscott added a comment.
I was helping to maintain v8js, and want to (eventually) use v8js to allow JS code in the Scribunto extension. I believe v8js has been migrated to PHP 7 already. Let me know if you have questions / want to fix specific bugs / etc.TASK DETAILhttps
cscott added a comment.
Some progress at https://wikimania2018.wikimedia.org/wiki/Program/Hackathon_Showcase including https://www.youtube.com/watch?v=j3GBJt6lL7s and https://en.wikipedia.org/wiki/File:FileAnnotation_with_Wikidata_statements_demonstration.oggTASK DETAILhttps
cscott created this task.cscott added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONI am developing an extension using EntitySelector. I would like to import a subset of wikidata items, but I need all (or almost all) the properties in order to make sense
cscott added a comment.
This property would probably have to be added to the Parsoid-format HTML in order to have any actual effect. But I'm not certain how/whether Google's search pipeline for WMF projects actually does anything with our content. We should probably talk to our contacts
cscott added a comment.
I've got a patch to fix the BCP 47 mappings in core: https://gerrit.wikimedia.org/r/442200
I'm hoping that if/when that's merged, we can remove some of the redundancy in wikibase and have wikidata just use the core code to do the remappings.TASK DETAILhttps
cscott updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION* `eml` does not exist, it should be `egl` (or `rgn`): T36217
* `map-bms` uses a very generic primary language subtag, it could for example use `jv-bms` instead
* `mo` does not exist, it should be `ro-md` (or `ro-cyrl
cscott added a comment.
roa-tara would more specifically be nap-x-tara, since it is a dialect of Neapolitan.TASK DETAILhttps://phabricator.wikimedia.org/T125073EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: cscott, hoo, XXN, Liuxinyu970226, Nikki
cscott added a comment.
There's a patch for proper BCP-47 validity conversion in core: I807dd55d49e9bd19443329231326a5b0d3e6c453TASK DETAILhttps://phabricator.wikimedia.org/T120847EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: cscott
cscott created this task.cscott added projects: Continuous-Integration-Infrastructure, Wikidata, Jenkins.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONparallel-lint is timing out and failing: https://gerrit.wikimedia.org/r/442209
@hashar thinks this is because:
[Wikibase has] a lot of php
cscott added a comment.
See also the UX mockup at https://phabricator.wikimedia.org/T146397#3241037TASK DETAILhttps://phabricator.wikimedia.org/T145458EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: MarkTraceur, Prtksxna, cscott, gerritbot, Matanya
cscott added a comment.
@daniel RdfWriterFactory comes from purtle, and has already been patched to add .jsonld. The patch to Wikibase should look something like https://gerrit.wikimedia.org/r/384050 but I can't test this locally.TASK DETAILhttps://phabricator.wikimedia.org/T44063EMAIL
cscott added a comment.
The patch has been merged, but https://www.wikidata.org/wiki/Special:EntityData/Q142.jsonld doesn't work yet. I assume a new version of purtle needs to be released, then wikidata's composer.json patched to require it? (https://gerrit.wikimedia.org/r/379669 is still
cscott added a comment.
It seems like Wikidata doesn't fully support wikis with LanguageConverter enabled? Does this same issue occur for zh-hans and zh-hant (and zh-hk, etc)?TASK DETAILhttps://phabricator.wikimedia.org/T121747EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
cscott added a comment.
@thiemowmde Nevermind, I got a little mixed up. I was concerned that -{zh:Foo;zh-tw:Bar}- would add an entry to the global translation table, in addition to specifying a one-time conversion. But that's not the case. You need to add the A or H (or -) flag to have global
cscott added a comment.
Hm, doesn't think -{...}- markup have side effects (ie, adding a rule to the conversion table) if the codes involved are languages, not scripts? Seems like you ought to be a little careful, since the "escape" function being used can have nonlocal effects.TASK D
cscott added a comment.
This is not related to the preprocessor change, it is long-standing bug in php LanguageConverter (to wit, conversion is applied at an awkward point in the parser pipeline, so it doesn't properly respect other syntactic structures). Sadly, LanguageConverter is riddled
cscott added a comment.
@daniel I don't think they are incompatible. They are both W3C standards; I believe JSON-LD is just an alternate representation of the RDF data. In fact, it ought to be "more compatible" than publishing an alternate JSON representation which is *not* grounded se
cscott added a comment.
It appears that we could support JSON-LD format without much trouble, which is the basis of the W3C Linked Data platform. In fact, there already exist JSON-LD processors for PHP, like https://github.com/digitalbazaar/php-json-ld and https://github.com/lanthaler/JsonLD
cscott added a comment.
I'm investigating making https://www.mediawiki.org/wiki/Extension:FileAnnotations implement the W3C standard for annotations ( https://www.w3.org/TR/annotation-model/ ) and REST API ( https://www.w3.org/TR/annotation-protocol/ ). These are based on the LinkedData standard
cscott added a comment.
The correct logic to determine if a language has variants doesn't involve looking at the fallback chain. See discussion in T153341.TASK DETAILhttps://phabricator.wikimedia.org/T156280EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
cscott added a parent task: T45547: MediaWiki needs a fictitious variant for English for easier variant development work.
TASK DETAILhttps://phabricator.wikimedia.org/T156280EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Smalyshev, Aklapper, cscott
cscott added a comment.
FWIW, detecting sr-el and sr-ec may be easy, but distinguishing zh-hk from zh-cn is *not*. The CJK character block in particular has big overlap problems, dating back to when we were worried about having only 64k characters in unicode.
Could someone edit the phab summary
cscott added a comment.
The logic for "should a language have languageconverter enabled" is pretty baroque; see the discussion in T153341. It's more-or-less $language->getConverter() instanceof FakeConverter. If you use that logic, Wikibase will work for pig latin. Unfortunately,
cscott created this task.cscott added a project: MediaWiki-extensions-WikibaseClient.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONSee gerrit failures for https://gerrit.wikimedia.org/r/72053
Wikibase makes the assumption that English won't have a variant
cscott added a comment.
If we use MCR for annotation storage, it would be useful to have a canonical URL for the contents of a specific slot. That might be an API URL, like https://en.wikipedia.org/api/rest_v1/page/html/Main_Page/749836961/<slot number> or else a user-visible URL like
cscott added a comment.
IIRC performance of some of the queries was a limiting factor to (for example) incorporating query results into infoboxes. Is that still an issue?TASK DETAILhttps://phabricator.wikimedia.org/T149326EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
cscott added a comment.
Discussed briefly at https://lists.wikimedia.org/pipermail/wikimedia-l/2016-November/085545.html:
my "big picture" vision here is that we start using our machine translation tools to tie our projects more tightly together, so we feel more like "one project a
cscott added a parent task: T147708: Facilitate Wikidev'17 main topic "Artificial Intelligence to build and navigate content".
TASK DETAILhttps://phabricator.wikimedia.org/T149666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Addsho
cscott edited the task description. (Show Details)
EDIT DETAILS...== Links ==
* ...* [Moses](http://www.statmt.org/moses/) open source *statistical* translation tool
* [Apertium](https://www.apertium.org/) open source *rule/dictionary based* translation tool
* Google's current statistical
cscott added a subscriber: Qgil.cscott added a comment.
In T114454#2788637, @Qgil wrote:
Who would be the person facilitating this session? Please assign this task to that person if you are aiming to have this session pre-scheduled. Thank you!
That would be me. Assigned. A reminder that TPG
cscott added a project: VisualEditor.cscott edited the task description. (Show Details)
EDIT DETAILS**Type of activity:** Pre-scheduled session.
**Main topic:** Handling wiki content beyond plaintext
== The problem ==
VisualEditor is a friendly means to edit *content*, but it presently provides
cscott added projects: Language-Team, MediaWiki-extensions-ContentTranslation, Wikidata.
TASK DETAILhttps://phabricator.wikimedia.org/T149666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: Qgil, Halfak, Amire80, cscott, Aklapper, Mohamedudhuman05
cscott removed a parent task: T147602: Facilitate Wikidev'17 main topic "Handling wiki content beyond plaintext".
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, cscottCc: Izno, Pppery,
cscott added a subtask: T107595: [RFC] Multi-Content Revisions.
TASK DETAILhttps://phabricator.wikimedia.org/T149532EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, cscottCc: Esc3300, Qgil, Catrope, greg, Aklapper, Jdforrester-WMF, GWicke, brion, Tgr
cscott added a parent task: T149532: Why Multi-Content-Revisions? Use cases and requirements..
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, cscottCc: Izno, Pppery, ggellerman, Alsee, Florian
cscott added a parent task: T147602: Facilitate Wikidev'17 main topic "Handling wiki content beyond plaintext".
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, cscottCc: Izno, Pppery,
cscott added a parent task: T147602: Facilitate Wikidev'17 main topic "Handling wiki content beyond plaintext".
TASK DETAILhttps://phabricator.wikimedia.org/T114454EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: MZMcBride, jeblad, Ph
cscott added a comment.
This proposal didn't actually get a session at the 2016 dev summit. It was elected as a topic for the all hands unconference, but when everyone showed up it turned out that all of the attendees (other than me) thought this was going to be a tutorial on authoring templates
cscott added a project: Wikimedia-Developer-Summit (2017).
TASK DETAILhttps://phabricator.wikimedia.org/T114454EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: cscottCc: MZMcBride, jeblad, Physikerwelt, RobLa-WMF, StudiesWorld, Krenair, Jdforrester-WMF, daniel
cscott added a comment.
@hoo's slides: F3203393: Magic Infoboxes.pdf
<https://phabricator.wikimedia.org/F3203393>
TASK DETAIL
https://phabricator.wikimedia.org/T112987
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: cscott
Cc: j
cscott added a comment.
I put together a few slides for an overview at the start of the session:
https://docs.google.com/presentation/d/1pFUIoC0rQioUBYEs5DQPVJvi9WdCXFEUebUdlo1v0RE/edit?usp=sharing
Hopefully @hoo can describe his stuff at the end, and maybe if @daniel is
present he can say
cscott added a subscriber: GWicke.
cscott added a comment.
@hoo Are you attending the summit? Can you talk a little bit about
https://phabricator.wikimedia.org/T114251?
@gwicke Can you talk a bit about Content Widgets?
@daniel Will you be there, can you talk about
https
cscott added a comment.
So one of my goals here is cross-fertilization. We've got a bunch of folks who
have worked on various flavors of "better infobox". I'd like to make sure we
get a chance to talk shop and say what we liked/didn't liked about our various
approaches, and see i
cscott added a subscriber: Jdlrobson.
cscott added a comment.
@hoo do you think you could pull together 2-5 slides for a "lightning talk" on
your work? Maybe pull from your [Wikimedia talk
https://wikimania2015.wikimedia.org/wiki/S
cscott added a comment.
Hey, @RobLa-WMF -- I noticed this is scheduled for an 80 minute slot starting
11:30AM on the first day of the summit -- opposite an open slot in the larger
Robertson 1. What's the expected format of this session? Should I start by
presenting an overview of the various
cscott added a subscriber: cscott.
TASK DETAIL
https://phabricator.wikimedia.org/T107595
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel, cscott
Cc: cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious,
Legoktm, Aklapper
cscott added a comment.
@Nemo_bis: we're just repeating the data provided by the `extmetadata` property
of the action API `imageinfo` query: https://gerrit.wikimedia.org/r/107562
We can grab AttributionRequired as well, but it would be nicer if `extmetadata`
would also give us a boolean
cscott added a comment.
We should get a boolean from the imageinfo API for this. Includable or
licensed or something like that. Certainly OCG shouldn't be trying to parse
license fields itself.
TASK DETAIL
https://phabricator.wikimedia.org/T75130
EMAIL PREFERENCES
https
1 - 100 of 101 matches
Mail list logo
