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)

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)

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

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

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