Topic: Epochtalk parser poll ! Come and vote your preference (Read 766 times)

I'm not so sure, writing is often quicker than clicking, especially if you also make use of the quick-reply solution instead of clicking "reply".

BTW, I made a poll to see which option is more popular, replies or quick replies:

https://bitcointalksearch.org/topic/--5289146

That would be really terrible
Think there would be suddenly 98% of the posts without formatting or coloring various text parts.
Since it is currently 19 to 1 for BBCode it looks pretty clear.

I've been spending a little more time at coinbistro lately and would be happy if a few more users would join in.
The progress is really very good and it is going in the right direction!

I'm in favour of sticking with BBCode (at least as long as we keep editor buttons so that we don't have to write the tags by hand ;))

While I like Markdown for content that benefits from being broken up into multiple sections (e.g. wiki pages, documentation, blog posts) I feel that for forum posts BBCode is a better fit. Maybe I'm just an old man not keeping up with the times though ;p

That would of course be optimal.
So, that's exactly how I could imagine it to be very practical and simple. Since I don't know which of the voting options is suitable for it, I don't click on any of the available ones
In any case, there must be buttons for the most common options because few users deal with the actual codes. It's very important that the formatting of the existing posts is nearly perfect... the most beautiful new board doesn't help us if the old posts are unreadable.

I've voted for BBCode. I love Markdown, above all for bulleted lists and the like, but I think it's important to have the less friction possible in the transition between the old forum and the new one. And I also see the problem with the asterisks in texts. So I think at least the "standard markup" language should be BBCode. And I agree with the fears that a hybrid would make things much more complicated.

The best option perhaps could be some sort of client-side converter from Markdown to BBCode, so markdown-fluent users can use it when they want without affecting the BBCode parser at all. Something like Showdown but with BBCode output, if this exists ... But I'm not an expert on this.

I have no experiences with other markup languages than BBcode thanks to this forum so I have already got used to it and I don't like chages so my vote goes to the keeping the BBcode and maybe add some more features to the existing one.. It's smart to make the migration as simple as possilbe

So many silent bbcode fans, speak up you cowards

Now seriously, after reading mprep's post and pondering this for a few days I must agree that I can't think of a really compelling reason to use markdown, at least not one being worth the complications.

I like markdown a lot for it's sheer simplicity but it also has disadvantages, e.g. if you happen to copy some text that happens to have two asterisks you may get unexpected results.

But I do hope that if we stick with bbcode we can get some enhancements - fully backwards compatible of course - like table borders.

It seemed a good idea at first (maybe) but indeed...

I agree 100% about the old posts.
The issue is mostly about future posts. An alert message when quoting old posts would help. The "post glitchiness percentage" in the alert is a cute idea.


That is definitely the plan and editor would be fitted with buttons


I totally understand your concern and I have no problem sticking to BBCode.
Regarding sigs it would be harder to manage. Doesn't sound that good to have the "new parser" for future posts at the same time the "hacky php parser" for displaying sigs below the posts going forwards.
Sigs change a lot, campaign ends etc and might not be that hard for them to adapt to a less quirky BBCode for example

As someone who occasionally goes on niche topic research binges during which I (on the regular) stumble upon numerous forums who have clearly undergone lackluster migrations (broken post markup, broken links, etc.), I'm gonna go with option 1. Adding any sort of complexity to a migration process (e.g. multiple markup languages, one way conversions on edit, etc.) is bound to break something as well as increase the ongoing cost of maintenance. And for what? A subjectively "easier" markup language (with potentially less features)?

Most people that use the forum either don't use any BBCode, use light styling touches (bold, italic, etc.) or know BBCode in and out and style their threads to the maximum extent the system allows. Those that either don't use BBCode or only do light styling aren't suddenly going to change their behavior and go all out with their posts / topics just cause they can use Markdown. And the users who put in massive amounts of effort into their content (which BTW includes complex signatures that often heavily rely on mountains of parser implementation quirks) will not only (potentially) have their old content mangled but have to learn the ins and outs of a new language as well as any specific implementation tricks of the Markdown parser to achieve anything even close to what they were able to previously.

---

Completely agree.

First, no hybrid please. Meaning the same post should have only one type of formatting applied to it. The current system tries to do bbcode and markdown at the same time and it ends up doing stuff like disappearing comments from code boxes.

Second, bbcode needs to be migrated 1:1. No matter how ugly the code is, run php in the backend if you must, it just needs to work. With all the quirks, like the squished first column in tables. Same styling/colors too. There's too much good old content dependent on all those bbcode quirks - it would be a shame to have it mangled.

Markdown for new posts is fine I think. I don't think tables are more painful than bbcode ones. You can use either HTML tables (essentially same structure as bbcode tables) or use the "|---|" syntax if the processor supports it - and I think it would make sense to have one that supports some sort of commonly used extended syntax set.

Editing an old post should give you two options - bbcode or one way conversion to markdown. It could even show an estimate of how glitchy conversion would be. If the post is using no bbcode or only simple tags like b and url - it should be fine. If it's full of tables and glows and what not - might show a more stern warning.

And there should be shortcut buttons for everything - from bold text to tables. We can't expect everyone to remember all codes, be it bbcode or markdown. But if bbcode is allowed only for editing old posts then perhaps it doesn't need a full featured editor. Not sure if that really saves any development effort though.

Reserved

Please read before voting !

Since these parsers are not standardized it's very hard to implement a mix of them without a bucket-load of bugs. That being said want to hear (read) your opinion on the matter. Which one do you like more ? Which one to use going forward ? ... considering all the trade-offs attached to each option.

The already existing posts (legacy) will have their own BBCode parser so they still look decent, even though full compatibility would be questionable. Making an exact 1 to 1 replica of the existing BBCode parser we use on bitcointalk doesn't sound that realistic but we can get close enough. The SMF parser is very disorganized and has lots of hard coded stuff so it somehow works.

@suchmoon made the below proposal:


Now the question is : keep BBCode or use more modern parsers or more user friendly ones for the future ?

Option 1: keep it a strict BBCode forum with the good and the bad

Option 2^*: have a Markdown parser for new posts. It currently is the most used markup language and is said to be more user friendly and "human readable". Some examples are github, discord, slack etc.
On the downside tables are a bit of a pain using it.
Also quoting legacy posts using Markdown would be an issue to tackle since converting them automatically from BBCode to Markdown would most definitely require some manual revision as it's not that exact.  

^* - this option includes a separate parser for legacy posts

Option 3: feel free to propose any other markup language or possibility.

Looking forward to read your on-topic thoughts and suggestions