Enable [[Project:Terminology gadget|Terminology gadget]] by default?
No, if this does not work, this does not mean that the support of Firefox as the base for the HTML/CSS parser and renderer implise that SeaMonkey uses a Javascript engine compying to ES6. The JavaScript engine is completely decoupled from the HTML/CSS parser and renderer Even if there's an interface between both engines, for access to the HTML DOM, or to the CSS properties from Javascript, or for handling HTML events into Javascript, this does not imply any dependency, they are completely independant. This means that the Firefox engine does not depend at all on ES6-compliancy, it does not even uses itself the Javascript engine, and may use its own regular expression engine (possibly even a different one for the CSS engine, with specific tunings for performances).
The Firefox Javascript engine has changed a lot (and in fact compltely rewritten) for performance so that it could still compete with the performances needed today and matched by other browsers (notably against the Javascript engine used by Chrome/Chromium, which uses an internal JIT compiler to native code running in a sandboxed VM). But Firefox also has recently changed its old API for plugins (including javascript engines) for security reasons and this probably breaks the compatiblity with existing extensions made in SeaMonkey, so that it could not easily replace the old Javascript engine by the new one based on the new plugin API (which now also supports most plugins made for Chrome/Chromium, and uses a much better handling of events, with asynchronous behavior and completions, multihreading and running scripts in a separate sandboxed VM, instead of the old system based on synchronous callbacks inside the same thread, which was really slow and extremely unsafe).
The exact statement from SeaMonkey is “Under the hood, SeaMonkey uses much of the same Mozilla Firefox source code.” (this does not mean it uses all its code).
Here is an example of Javascript polyfill needed for SeaMonkey, even for navigating in its own GitHub repository:
There's a (slow) fix there demonstrating that SeaMonkey does NOT respect the ES6 requirements for regexps in its embedded Javascript engine!
You'll see in that polyfill that ES6-compliant regexps using Unicode properties on Unicode codepoints do not work (such as the line commented out no https://github.com/JustOff/github-wc-polyfill/blob/master/bootstrap.js#L475 which uses UCD properties like "\\p{Emoji}" and numerical codepoint references like "\\u{1f300}" for characters outside the Unicode BMP: this is required also for modern languages, including Chinese, mathematical symbols, and almost all emojis, or languages supported in MediaWiki which are using scripts entirely written outside the BMP, such as Gotic, or newly-encoded Asian and African scripts, all of them needing characters in "supplementary planes"). These characters may be supported in the HTML/CSS parser and renderer, without being really supported in the Javascript engine (historically Javascript used only flat 16-bit encoding, and had limtied character properties defnied only ion the BMP, treating all non-BMP characters all as "opaque" surrogates without any other properties; so nothing was made in its embedded regexp engine, and in fact it did not even have a full UCD support for all characters of the BMP, only basic POSIX properties on ASCII, possibly extended to ISO889-1 only but with bugs when there was another locale in use: the Javascript engine was not using exclsuively UTF-16 when working with the HTML DOM and CSS; these old APIs were broken!).
This means that the regexp engine used in SeaMonkey DOES NOT conform to ES6 and that SeaMonkey does not really support Unicode, and treats strings only as opaque vector of 16-bit "characters" without properties; it also uses some "custom" non-standard flags in regexps. ES6 added the required support of Unicode codepoints, not just the basic interface with opaque 16-bit encodings and basic character properties on ASCII characters; it also adds the required support of Unicode codepoint ranges (not just 16-bit codeunit ranges), character properties from the Unicode UCD, at least for general categories), and Unicode normalizations. The regexp engine complying to these rules are obviously more complex to integrate, but this has been done in a real Javascript engine for real Firefox, as well as the one in Chrome/Chromium, Edge, Safari and most other browsers... (for Chrome/Chromium-based Javascript engines this is an optimized version, other browsers generally use the ICU library for all these purposes; writing a *performant* Unicode-compliant regexp is very challenging, expecially with Unicode extensions; other projects had similar difficulties, notably Perl which was the first to offer full Unicode-compliance in PCRE, even before if was standardized in ES6 for Javascript, even if ES6 does not require all PCRE extensions).
Note that even if you think tht non-BMP characters are not needed for your language when navigating the web (e.g. you don't know Chinese or Asian and African languages needing them for their scripts), this is no longer true, at least on many social networks and many sites that now use many emojis. As well on Mediawiki, emojis are accepted in page names, user names, and are even used now in some messages (notably for the mobile interface).
There are specific rules that may be applied to emojis or other non-BMP characters that must match in Javascript regexps, or for transforming the content. MediaWiki has full support of non-BMP characters (except on some legacy wikis that were installed with old versions of Mediawiki that were installed with some old database engines tht were not converted to use full Unicode encodings and that were limited to just BMP characters: these wikis are broken, causing various issues each time there's a non-BMP character entered, because they validate inside Mediawiki but fail to be stored and retrived correctly to/from the underlying database: this is a documented problem that administrators of these wikis must handle themselves, because this requires an offline database maintenance, and possibly a very long time to reindex all its content for the new encoding; this is not the case of Wikimedia wikis whose database storage have been updated since many years, by using UTF-8 or UTF-16 everywhere, and no longer the old UCS2 encoding supporting only characters in the BMP or multibyte-encoded characters needing more than 2 bytes in the database encoding); if these wikis are not upgraded, any attempt to retrieve and parse the stored wiki content causes a fatal server-side error if there's a single non-BMP character in it (and Mediawiki itself silently accepts to store these contents that will make the page uneditable or truncated silently!). In other words, Mediawiki requires full Unicode support for all 16 supplementary planes on the server side, and these characters must not break the JavaScript regexp rules used by the UI on the client side.
Well, I do see the character for Japan here, and this page looks scripted to me: https://unicode-table.com/en/search/?q=%F0%9F%97%BE
The implementation of JavaScript in SeaMonkey is called SpiderMonkey, and I have no doubt that it's the same version from Firefox 60, but still being patched. That's not an ideal situation, of course.
Seeing the characters for Japan in the HTML/CSS parser and renderer is not a sufficient condition. We are talking about Javascript support of regular expressions.
Once again the regular expression engine used in Javascript (with ES6) is absolutely never needed to parse and HTML and render texts, and for supporting fonts with supplementary characters that are outside the BMP. You could disable Javascript entirely in the browser, you would still see the same Japanese text (however you would not interact much with web sites using only HTML and CSS, at least not with client-side scripts, but only via HTML form submissions processed on the server, or with active media "objects" like audio and videos which embed their own interactions wit hthe user and communication with the remove servers, without actually modifying the HTML and CSS structure of the documetn you're viewing and navigating via HTML hyperlinks, but form submission buttons; as well all data validation would be performed by the server, and navigation would be really slow, forcing whole HTML pages to be reloaded to reflect the new states implied by user interactions).
This suggests that the Terminology gadget should perform a Javascript Regexp capacility tests to see if the browser conforms to ES6, so that it will disable itself and instruct their users to use it with another (ES6-compliant) browser. Other non-ES6 compliant webbrowsers that are still sold and used today are "smart TVs" (not those coslty models with Android, but most Chinese TV brands, using very limited browsers like Opera Mini), and some very cheap smartphones that were recycled and refurbished in poor markets, but only usable to make phone calls and not to use webapps or browse the web (though, modern chip smartphones, made in China, are probably sold at better prices than buying old refurbished smartphones, whose main interest will not be their use on the web, but their extended battery charge time, when the web is not used, there's no wiki and no 3G+ mobile data network, and there's not energy-intensive displays).
(old Nokia, Blackberry and Windows Phones are no longer sold since years, and probably now all defunct, for having lost all support since years and not even being able to use any apps due to very insufficient of storage space, even just for updated noly their embedded apps; there's no change to get any newer browser on these devices, whise batteries are also probably dead since long)
TL;DR Lost my interest in this thread. Off-topic parts can be removed. thx
Note that there's a new error message available since today (to be translated) that warns users when their web browsers does not have a Javascript engine not compatible with ECMAScript 6 (ES6).
- Gadgets-requires-es6 ("This gadget is only supported on ES6-compliant browsers")
It should be displayed now for such gadget.
Insults are very unwelcome. I did not insult you or any one, but your reply was effectively doing SOMETHING wrong here which is not accepted (read the contributor terms, guidelines, and help pages).
I just tried to give some explainations and fix some incorrect assumptions, so that you could eventually make your choice. We are not supporting any browser development here, so that's not the place to bring your birds terms here. And the message I jsut showed was not created by me but shows that I was right and that existing MediaWiki developers have no time to support non-ES6-compliant browsers (unless you want to find solutions and support them to help that project).
Both "piss off" and "rumble" are characterisations of the other person's actions or intent which are unnecessary because they do not convey additional information, and therefore can be perceived as personal attacks. I'm not sure what's going on here, but perhaps we can all tone down?
Yes but "piss off" is really insulting directly against someone, while "rumbling" is a descriptive attitude. And I gave te asme argument as you when I signaled it to Nick before your reply, Nemo. I admit that PiefPafPier is not pleased of this situation, but what I posted jsut before his reply was a revealing an effective fact, which may also be related to this extension and recent discussions (and not directed at all against him or any one).. It also jsut says that existing developers have no time to invest for now in trying to support all browsers (and for indefinite long time), when they already have lot of other priorities for many other people. If that user wants to change that and has technical capabilities and enough time, he should help another way by explaining what fixes he found that may work (but proably this is not needed: gadgets are extensions that can be disabled and replaced by user gadgets that they develop test and fix themselves.
"Pissed off" may also be an accurate description of how someone feels, while "rumbling" is often a subjective judgement of someone else's actions.
That's completely the opposite of what I perceive, and any translation would treat the former as a strong slang word, not the later one which is very weak, and frequently used by people for themselves. I've seen that term frequentl used by official supports and moderators in forums, and by developers that receive offensive comments, when these supprots are treated being "lazy", or not abeing able to support a request which is postponed or abandoned later when stalled without possible action for too long (but no one was initerest to provide a patch, maintenance or review, but users just complain and reject other proposed solutions/alternatives). Here he was propsoed an alternative that is well supported (he has the choice of supported browsers for his platform, we are not forcing them). I understand his deception. But how would you decribe the reaction he unexpectedly had above? See for example how Quora describes it (and what moderation action they may take if someone acts like this); there are similar rules in moderated and reviewed social networks (like 4chan, Reddit), or support forums (Microsoft, Oracle), but unfortunately not in most others (Twitter, Facebook, do nothing unless there's a violation of law, or violation of their censorship on some topics, even if it's perfectly legal and respectable, including very wellknown artworks in museums)...