User talk:Remember the dot/Syntax highlighter.js

Bug with parser function inside external link
This syntax does not highlight properly in Firefox 32.0.3 on Windows:

[ my text]

The  gets highlighted in yellow, but the external link syntax around it does not. I realize this is a tricky case because the syntax highlighter doesn't call the fullurl parser function, but maybe fullurl is common enough that it should be handled specially. --Maiden taiwan (talk) 15:33, 10 October 2014 (UTC)


 * I think the fullurl syntax is different in different languages, which would make handling it difficult (this is the same reason why etc. are not highlighted). Maybe it's time to engineer in a language pack system to grab the localized text you need for your language and no others. To be honest though, I'm not sure that what you're doing is all that common, and maybe it could be better handled by writing a template that makes a fullurl link automatically. —Remember the dot (talk) 16:59, 10 October 2014 (UTC)


 * Thanks for your quick reply! The fullurl pattern is the recommended solution when you're creating local links with query string arguments, like . On our wiki, this is reasonably common. Anyway, I hope my suggestions are helpful. Maiden taiwan (talk) 18:29, 10 October 2014 (UTC)

r.style.clear = "both";
Just wanted to report that in order to make the highlights match the text on Persian Wikipedia I had to add  to the code (which I think was required because of the special style of some of our toolbars). Thanks for this great gadget. Dalba 27 Aban 1393/ 11:11, 18 November 2014 (UTC)


 * I just tried the mainline code on the Persian Wikipedia and I didn't see any problems. What browser and skin are you using? Have you enabled any special toolbars? (And by the way, the actual source code is at User:Remember the dot/Syntax highlighter.js.) —Remember the dot (talk) 06:57, 19 November 2014 (UTC)
 * I'm using FF 33.1, vector skin. Yes, I've enable a non-default gadget (toolbar) on my account (Sorry that I didn't mention this before, I thought it is a default gadget). To reproduce the problem I think you need to run the code in this gadget so a toolbar will be added to top of the editbox. Then run your own code. Dalba 28 Aban 1393/ 07:26, 19 November 2014 (UTC)
 * I thought this over and I decided to adopt your solution. The syntax highlighter forces the textbox to width:100% anyway, so I don't see the harm in clearing floating elements too. —Remember the dot (talk) 05:56, 11 December 2014 (UTC)

Detecting changes to the text direction
As an RTL user I frequently need to switch direction of the text (using ctrl+shift+x in Firefox), but the direction of highlights is not changed accordingly. I don't know if it's possible or not, or how much it could affect the performance of the script, however it would be very nice if DotsSyntaxHighlighter could detect this. Thanks. Dalba 20 Azar 1393/ 06:51, 11 December 2014 (UTC)


 * Done. Would you like to contribute a Farsi translation of errorMessage while you're at it? —Remember the dot (talk) 18:58, 11 December 2014 (UTC)
 * Sure, I will be glad to. Here it is:
 * - Dalba 20 Azar 1393/ 22:19, 11 December 2014 (UTC)
 * - Dalba 20 Azar 1393/ 22:19, 11 December 2014 (UTC)

Fix error caused by elements
Can the code  be replaced with. Or line 204 from the better formatted script from if (text.charAt(tagEnd - 2) == "/" ) to if (text.charAt(tagEnd - 2) == "/" || match[0].substring(1) == "br" )

This will allow the script automatically treat  elements as self closing, since they are.

Also, is there any specific reason the code here uses generic variables and no whitespace? --KnightMiner (t/c) 16:45, 15 June 2015 (UTC)


 * I am not going to maintain a massive whitelist of every self-closing element that could possibly exist. Use  instead. —Remember the dot (talk) 20:08, 15 June 2015 (UTC)


 * I am not going to edit every article on Wikipedia just to replace  with   just so I can have the syntax highlight work (especially since   is both perfectly valid HTML5 and commonly used). If you do not want to maintain a list, at least add a feature for a user to define their own list (such as by adding the case  .). --KnightMiner (t/c) 22:11, 15 June 2015 (UTC)


 * While adding a config option would be more palatable than maintaining a list, it would still place a sizable burden on the site administrators to make sure that the list of self-closing tags is exactly correct for the MediaWiki extensions installed on the site, taking into account that the tags may have different names in different languages. Also, standardizing on one tag form gives wikitext a more consistent appearance that is less confusing to people new to HTML. The argument that  should be supported because it is "valid HTML5" is not a great argument because HTML5's purpose was to make any widely supported design decision "standard" no matter how bad of an idea it was. In fact, even though it would be "valid" to leave   alone, MediaWiki automatically normalizes it to   in the page output so that every page can be manually inspected with ease or parsed with a simple, low-overhead XML parser. In the same way, adding support for implicitly closed tags would also slow down the syntax highlighter's parser, and the #1 complaint about it has been that it's too slow already.
 * Long story short, I think the right thing to do is to gradually phase out implicitly closed tags in favor of explicitly closed tags in order to present a simple, clear syntax to users, minimize the burden on site administrators, and maximize highlighting speed. I don't expect you to agree with me, but I hope that you can at least see that this way forward has its advantages. I do have a question for you: Why are you using  directly in the first place? Why not build it into templates and use it directly as little as possible? —Remember the dot (talk) 22:55, 15 June 2015 (UTC)


 * Yes, standardization would be a easier (and faster) solution, but as it is currently not deprecated, I still conciser it more convenient. Also, until the software stops supports using it, I cannot see the users stopping using it even should it become deprecated, as quite a few times I have seen someone add a deprecated parameter (like  on a div) simply because it is shorter.
 * Specific cases I tend to see it include within table cells (such as on the articles on the various Doctor Who series) and talk pages (which better control formatting in the case of bullet lists and the occasional signature to add two half-height inline words). --KnightMiner (t/c) 01:49, 16 June 2015 (UTC)

&lt;br> is standard, users believe they edit the text in HTML-like style, not XML. Too much of a burden to follow every user and ask to use &lt;br /> instead, not to mention that it requires unnecessary keystrokes. Browsers have accelerated in recent times, I believe the performance would not suffer much. Jack who built the house (talk) 15:10, 9 June 2016 (UTC)
 * +1 This is the only major drawback of this gadget, not being able to highlight properly the text when  is used. And changing every page on every wiki is simply not an option. I don't know if MediaWiki normalization will keep producing   if the replacement of Tidy is done as planned (phab:T89331). --NicoV (talk) 12:18, 22 July 2016 (UTC)
 * For those who are interested, I have made a version that handles void tags defined by the HTML5 standard (just br and hr, as I believe the other ones are not working in wikitext) User:NicoV/Syntax highlighter.js (very few modifications). It's not minified yet, but if some of you want to test it (KnightMiner, Jack who built the house). --NicoV (talk) 10:59, 27 July 2018 (UTC)
 * We had to fork the original version long ago in ruwiki because of this issue, see ru:MediaWiki:Gadget-DotsSyntaxHighlighter.js. Anyway, there is a new native syntax highlighter (based on CodeMirror) which supports, so I see people are switching to using it. Jack who built the house (talk) 11:09, 27 July 2018 (UTC)
 * Thanks for the link to ruwiki version. I know about the new syntax highlighter, but I prefer to stick with the old one, because it's easier to fix errors like the ones from Special:LintErrors/missing-end-tag with it: the missing end tags tend to be very visible with this gadget, and almost invisible with the new one. --NicoV (talk) 12:27, 27 July 2018 (UTC)

Ru localization
Please add russian variant for ErrorMessage: Alex Great (talk) 05:17, 15 August 2015 (UTC)


 * Done, thank you! —Remember the dot (talk) 08:28, 15 August 2015 (UTC)

Подсветка синтаксиса на странице была отключена, так как заняла слишком долго. Максимальное допустимое время операции - $1мс, сейчас на вашем компьютере она заняла $2мс. Попробуйте закрыть несколько вкладок и программ, затем нажать «Предварительный просмотр» или «Внесённые изменения». Если это не поможет, попробуйте другой браузер; если и это не поможет, используйте более быстрый компьютер. Ivan Pozdeev (talk) 22:28, 30 May 2016 (UTC)
 * I dunno how Alex translated it, but it looks like machine translation. A few expressions are plain wrong and general phrasing is weird. Here's a more human version:

Re evaluate ms edge support
Hi please could you re evaluate support for ms edge since I see it is blacklisted but with the November update it included some big changes to edge could you see if the bugs are fix so support can be re added please. 94.195.93.42 17:58, 22 November 2015 (UTC)

Korean translation
ko:이 문서에서의 문법 강조가 너무 오래 걸러서 해제되었습니다. 최대로 할당된 강조 시간은 $1ms인데, 당신의 컴퓨터는 $2ms이나 걸렸습니다. 탭과 프로그램을 일부 닫으신 후에 \"미리 보기\"나 \"차이 보기\"를 클릭하시기 바랍니다. 만약 작동하지 않으면 다른 웹 브라우저로 시도해보시고, 그래도 안되면 더 빠른 컴퓨터를 이용하십시오

Please add this.--Namoroka (talk) 06:16, 30 April 2016 (UTC)


 * Done, thank you! —Remember the dot (talk) 00:59, 3 May 2016 (UTC)

Italian translation
it: L'evidenziazione delle sintassi su questa pagina è stata disabilitata perché ha richiesto troppo tempo. Il tempo massimo per l'evidenziazione è di $1ms e al tuo computer sono serviti $2ms. Prova a chiudere alcune schede e programmi e ricarica la pagina cliccando su \"Visualizza anteprima\" o \"Mostra modifiche\". Se non funziona ancora, prova con un web browser differente e, in ultima alternativa, prova ad utilizzare un computer più veloce. -- Fringio — α†Ω 09:06, 29 June 2016 (UTC)


 * Done, thank you! —Remember the dot (talk) 04:16, 16 April 2017 (UTC)

Armenian translation
hy: "Շարադասության ընդգծումը այս էջում անջատվել է, քանի որ այն չափից շատ է տևել։ Ընդգծման թույլատրելի առավելագույն ժամանակը $1 միլիվայրկյան է, բայց այս էջում տևել է $2 միլիվայրկյան։ Փորձեք անջատել որոշ ներդիրներ կամ ծրագրեր և սեղմել «Նախադիտել» կամ «Կատարված փոփոխությունները»։ Կրկին չաշխատելու դեպքում փորձեք այլ վեբ դիտարկիչ, եթե կրկին չաշխատի, փորձեք ավելի արագ համակարգիչ։",

Please add this.--Ashot (talk) 11:35, 17 July 2016 (UTC)


 * Done, thank you! —Remember the dot (talk) 04:16, 16 April 2017 (UTC)

Sr localization
Please add serbian variant for ErrorMessage: --Ранко Николић (talk) 00:09, 25 March 2017 (UTC)


 * Done, thank you! —Remember the dot (talk) 04:16, 16 April 2017 (UTC)

TypeError: $.client is undefined
https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-DotsSyntaxHighlighter.js triggers the following error: TypeError: $.client is undefined Maybe due to T122755 --AKlapper (WMF) (talk) 14:07, 5 May 2017 (UTC)
 * It looks like it could be fixed by adding dependency on "jquery.client" in ResourceLoader: https://uk.wikipedia.org/w/index.php?title=MediaWiki%3AGadgets-definition&type=revision&diff=20255414&oldid=20255370 --DixonD (talk) 17:55, 5 May 2017 (UTC)
 * That dependency has been already in place?: https://www.mediawiki.org/wiki/MediaWiki:Gadgets-definition --AKlapper (WMF) (talk) 10:17, 7 May 2017 (UTC)
 * Which site do you see the error on? —Remember the dot (talk) 04:08, 9 May 2017 (UTC)

Sorry! We could not process your edit due to a loss of session data.
Hi, I have a strange error when I change the location of your original script (from mediawiki.org) to another private common site (named here fr-ii.demopaedia.org). All the MediaWiki:Gadget-DotsSyntaxHighlighter.js files of my wiki farm (en-ii.demopaedia.org, it-ii.demopaedia.org etc) are changed from: mw.loader.load('//www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-DotsSyntaxHighlighter.js&action=raw&ctype=text/javascript'); to mw.loader.load('//fr-ii.demopaedia.org/w/index.php?title=MediaWiki:Gadget-DotsSyntaxHighlighter.js&action=raw&ctype=text/javascript'); excepting the master fr-ii.demopaedia.org/w/index.php?title=MediaWiki:Gadget-DotsSyntaxHighlighter.js which content is filled with your original javascript code (not by another mw.loader.load from mediawiki).

On the master fr-ii site, everything works, I can edit (with colored witki syntax) and save modifications, but on any other site (en-ii.demopaedia.org, etc) if I can edit (with colored wiki syntax), I can't save my modifications, and it is said:

''Sorry! We could not process your edit due to a loss of session data''.

''You might have been logged out. Please verify that you're still logged in and try again. If it still  does not work, try logging out and logging back in, and check that your browser allows cookies from this site.''

Any idea in the settings of my wiki farm which involves such a bizarre behaviour?

My purpose is modify your original code in order to highligt differently "named" templates (otherwise they are all yellow), but to keep the modifications in a single master (private) site loaded by each wiki of the farm.--Nbrouard (talk) 11:20, 19 June 2017 (UTC)


 * I honestly don't know. Does the problem still happen if you turn off the syntax highlighter? —Remember the dot (talk) 15:12, 22 June 2017 (UTC)
 * Thank you for your prompt answer. Glad to know that you don't know. Yes, if syntax highlightter is off, we don't have this message (as well as no syntax highlighting). Thus, because import doesn't work, I will have to upload the source code in any language of our dictionary and for any modification.
 * We have a lot of template and wiki source was unreadable. Now it is better, text to be modified or to be read is in white. Templates are in different colors.
 * We also have "notes" which are in green.
 * If you are curious and want to look at section 10 of the English demographic dictionary http://en-ii.demopaedia.org/wiki/10 and its source highlighted code http://en-ii.demopaedia.org/w/index.php?title=10&action=edit
 * The modified javascript ocde is at http://en-ii.demopaedia.org/wiki/MediaWiki:Gadget-DotsSyntaxHighlighter.js
 * I use your recursivity in the templates but have to find their name and the vertical bar which stops the recursivity and his very specific to our template. I appreciated the way how you sinc.
 * Many thanks. --Nbrouard (talk) 19:20, 24 June 2017 (UTC)

Empty space
Hi, some users have noticed an empty space between the textarea and the edit toolbar, see screenshot. The problem can be replicated in mediawiki.org enabling "Dot's syntax highlighter" in preferences/gadgets and then editing a page. --Rotpunkt (talk) 10:02, 18 April 2018 (UTC)


 * I've noticed this too. I'll look into it. —Remember the dot (talk) 15:06, 18 April 2018 (UTC)


 * I think I fixed it. Apologies for not dealing with this problem until you mentioned it. Please let me know if you notice anything else that looks wrong. —Remember the dot (talk) 15:25, 18 April 2018 (UTC)


 * Thanks for your fix and your support! Cheers. --Rotpunkt (talk) 15:37, 18 April 2018 (UTC)

Belarusan localisation
Hello. Please add these: --Renessaince (talk) 09:53, 24 July 2018 (UTC)


 * Done, thank you! —Remember the dot (talk) 06:30, 29 July 2018 (UTC)
 * Are You sure it will work with «be-tarask» code as well? (not «be»). --Renessaince (talk) 08:52, 30 July 2018 (UTC)
 * All Belarusan dialects will see the same message, yes. Do you need different messages for different dialects? —Remember the dot (talk) 05:38, 1 August 2018 (UTC)
 * Ok, it fits for now. Thanks. --Renessaince (talk) 15:49, 2 August 2018 (UTC)

Bug concerning the highlighter in French Wikipedia
Hello,

I'm a French contributor and I'm using the highlighter gadget when editing wikicode.

It appears that the tag  induces coloring of the text when it should not do (because Madiawiki is expecting a closing tag, which obviously never appears) : this phenomenon imposes to use the old one.

Is there a possibility to fix this bug ? If not, there will be necessary to continue to use the old tag  which pretendingly disappeared with html5.

Please do not hesitate to ask if my request is unclear.

Thanks in advance. Best regards. --Gkml (talk) 15:27, 12 December 2018 (UTC)


 * Both  and   are perfectly acceptable in HTML5. The syntax highlighter accepts only   for consistency and performance. It's usually better to use templates instead of inserting   directly into the page anyway. —Remember the dot (talk) 07:32, 17 December 2018 (UTC)
 * Thank you for the answer Remember the dot. What do you mean exactly with "It's usually better to use templates" ? Because there are many cases where you have no choice. Regards. --Gkml (talk) 17:48, 21 December 2018 (UTC)


 * For example, if you have a template that takes a single parameter for both an image and its caption (and it expects you to put a  between the image and the caption), it's better to redesign the template to have a parameter for the image and a separate parameter for the caption. —Remember the dot (talk) 03:48, 22 December 2018 (UTC)

zh-hans localization
简体中文本地化

Please add zh-hans(Simplified Chinese) variant for ErrorMessage:

請為錯誤消息添加简体中文（代碼）變體： Please add this

請添加這些--Zyksnowy (talk) 08:56, 9 February 2020 (UTC) --Zyksnowy (talk) 11:42, 30 March 2020 (UTC)


 * Done, thank you! Currently all Chinese-language users will see the same message, but if you come up with a separate Simplified Chinese message then I am happy to add that too. —Remember the dot (talk) 05:53, 31 March 2020 (UTC)

Compare with new design
Hi, the developers recently updated the WikiText editor (T174119) and now, for example, the border  is not needed. Can you update the design due to changes? Iniquity (talk) 20:02, 11 May 2020 (UTC)


 * Thanks for letting me know! I just updated the script to be able to handle arbitrary border styles, which I'm hoping will resolve this problem no matter how MediaWiki's various skins are changed in the future. —Remember the dot (talk) 03:27, 12 May 2020 (UTC)
 * Thank you! :) I would like to know, can all the inline styles be transferred to some class? This will help users who want to change the textarea. Iniquity (talk) 13:28, 12 May 2020 (UTC)


 * The styling of the textarea and the background div have to be kept practically identical. Since there is no way to detect changes to CSS that might affect the style of the textarea, the highligher simply reads what the textarea style is when the page loads and then locks it to those values via the style attribute. So users are able to do a large amount of customization of the textarea style, they just can't change the style dynamically after the page has loaded. (Although actually they could change the textarea styles arbitrarily after the page loads as long as they were to be careful to change the background div in the same way.) —Remember the dot (talk) 06:34, 17 May 2020 (UTC)