On 08/03/2016 10:48 PM, Subramanya Sastry wrote:
On 08/03/2016 07:17 PM, Rob Lanphier wrote:
On Mon, Aug 1, 2016 at 10:15 PM, Subramanya Sastry
wrote:
...
I think it is feasible to get there. But, whether we want a spec for
wikitext and should work towards that is a
https://www.mediawiki.org/wiki/Specs/wikitext/1.0.0
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Aug 3, 2016 at 8:48 PM, Subramanya Sastry wrote:
> On 08/03/2016 07:17 PM, Rob Lanphier wrote:
>> In our planning meeting (E250), we discussed this issue as a
>> possibility for next week's ArchCom office hour (E259). We don't
>> (yet) have a specific RFC we can
On 08/03/2016 07:17 PM, Rob Lanphier wrote:
On Mon, Aug 1, 2016 at 10:15 PM, Subramanya Sastry
wrote:
When [a detailed list of stuff is] done, it become far more feasible to think
of defining
a spec for wikitext parsing that is not tied to the internals of mediawiki
or
On Mon, Aug 1, 2016 at 10:15 PM, Subramanya Sastry
wrote:
> When [a detailed list of stuff is] done, it become far more feasible to think
> of defining
> a spec for wikitext parsing that is not tied to the internals of mediawiki
> or its extensions. At that point, you
Subramanya Sastry wrote:
>Some user pages seem to exploit this as a feature even (unclosed div
>tags).
Not just some and not just seem. :-) Thank you for this detailed e-mail.
John Mark Vandenberg wrote:
>The main reason for a spec should be the sanity of the Wikimedia
>technical user base,
TL:DR; You get to a spec by paying down technical debt that untangles
wikitext parsing from being intricately tied to the internals of
mediawiki implementation and state.
In discussions, there is far too much focus on the fact that you cannot
write a BNF grammar or yacc / lex / bison /
On Tue, Aug 2, 2016 at 8:34 AM, Gergo Tisza wrote:
> On Mon, Aug 1, 2016 at 5:27 PM, Rob Lanphier wrote:
>
>> Do you believe that declaring "the implementation is the spec" is a
>> sustainable way of encouraging contribution to our projects?
>
>
>
On Mon, Aug 1, 2016 at 5:27 PM, Rob Lanphier wrote:
> Do you believe that declaring "the implementation is the spec" is a
> sustainable way of encouraging contribution to our projects?
Reimplementing Wikipedia's parser (complete with template inclusions,
Wikidata fetches,
There is a slow moving discussion about this at
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Markdown
The bigger risk is that the rest of the world settles on using
CommonMark Markdown once it is properly specified. That will mean in
the short term that MediaWiki will need to support
On Mon, Aug 1, 2016 at 1:56 PM, Gergo Tisza wrote:
> On Mon, Aug 1, 2016 at 1:01 PM, Rob Lanphier wrote:
>> On Mon, Aug 1, 2016 at 12:19 PM, Gergo Tisza wrote:
>> > Specifying wikitext-html conversion sounds like a MediaWiki 2.0
> One possibility is considering storing rendered HTML for old revisions. It
> lets wikitext (and hence parser) evolve without breaking old revisions.
Plus
> rendered HTML will use the template revision at the time it was rendered
vs.
> the latest revision (this is the problem Memento tries to
On 1 August 2016 at 17:37, Marc-Andre wrote:
> We need to find a long-term view to a solution. I don't mean just keeping
> old versions of the software around - that would be of limited help. It's
> be an interesting nightmare to try to run early versions of phase3 nowadays,
On Mon, Aug 1, 2016 at 1:01 PM, Rob Lanphier wrote:
> On Mon, Aug 1, 2016 at 12:19 PM, Gergo Tisza wrote:
> > Specifying wikitext-html conversion sounds like a MediaWiki 2.0 type of
> > project (ie. wouldn't expect it to happen in this decade), and
On Mon, Aug 1, 2016 at 12:19 PM, Gergo Tisza wrote:
> Specifying wikitext-html conversion sounds like a MediaWiki 2.0 type of
> project (ie. wouldn't expect it to happen in this decade), and even then it
> would not fully solve the problem[...]
You seem to be suggesting
On Mon, Aug 1, 2016 at 11:47 AM, Rob Lanphier wrote:
> > HTML storage comes with its own can of worms, but it seems like a
> solution
> > worth thinking about in some form.
> >
> > 1. storage costs (fully rendered HTML would be 5-10 times bigger than
> > wikitext for that
On Mon, Aug 1, 2016 at 9:51 AM, Subramanya Sastry wrote:
> On 08/01/2016 11:37 AM, Marc-Andre wrote:
>> Is there something we can do to make the passage of years hurt less?
>> Should we be laying groundwork now to prevent issues decades away?
>
>
> One possibility is
"Should we be laying groundwork now to prevent issues decades away?" I'll
answer that with "Yes". I could provide some interesting stories about
technological and budgetary headaches that result from repeatedly delaying
efforts to make legacy software be forwards-compatible. The technical
details
On 08/01/2016 11:37 AM, Marc-Andre wrote:
...
Is there something we can do to make the passage of years hurt less?
Should we be laying groundwork now to prevent issues decades away?
One possibility is considering storing rendered HTML for old revisions.
It lets wikitext (and hence parser)
19 matches
Mail list logo