Enable [[Project:Terminology gadget|Terminology gadget]] by default?
Hi! I downloaded SeaMonkey to see what was wrong, and there was a regex it didn't like. I fixed that, but now there's another regex it doesn't like. Since SeaMonkey has minuscule use and the current version is based on a Firefox version from 2018, I don't think it's worthwhile to spend more time trying to fix it – I'd recommend using a more modern browser instead, or waiting until they update it to a more current Firefox version.
Wow, then it's lagging behind a lot! Thank you for looking into this.
IF it was based on Firefox 2018, it would support ES6 (ECMAScript 6, i.e. ECMA standard 262 for Javascript) from 2016; adn would then have all what is necessary for regexps. Most probably SeaMonkey uses a very antique Javascript engine that does not even support ES6. So lot of scripts won't work because ES6 is the based standard for all modern browsers (even IE11 had support for the same level of Regexp standardized in ES6).
This also means that SeaMonkey or most probably not secure at all and does not implement many sandboxing features needed today no the web (for your security or privacy) and will be extremely slow when using polyfills (for emulating regexps). For these reasons, you should xconsider abandonning that webbrowser with a more maintained one: today there remains only three major web browser bases: Safari (required base for iOS and OSX), Firefox, and Chromium/Webkit (for most other browsers, including Chrome, Android, Edge, Vivaldi, Opera...). And 3 base Javascript engines (today now only Safari lags a bit behind, but it is still supported). For mobile environments, only Safari/iOS and Webkit/Android. Firefox is now mostly used on Linux, but various wellknown distribs have decided to drop it in favor of a Chromium-based webbowser (including for their desktop environments, e.g. with KDE).
I use Linux and FOSS. I like Firefox on Android, but on PCs I think it's too simplistic. The security of SeaMonkey doesn't worry me that much, because they are still backporting fixes. I never use it for tricky stuff. The rendering engine upgrade is long overdue though, and is becoming annoying. But I'm patient, I don't want to lose my proggie yet. :-)
Use this browser as you want for other sites. It's just that it's not usable for using TranslateWiki.net (or the Translate UI extension in other MediaWiki sites). The priorities for now in MEdiawiki was to offer better accessiblity with modern and secure browsers on most common desktop and mobile systems, and it's a fact that today there's a large and accelerated move to use modern browsers that are confoming at least to ECMAScript 6.
SeaMonkey probably does not have support for Unicode-based regular expressions (standardized in ECMAScript 6 since many years), which are REQUIRED for correct management of translations. The translate UI cannot be reliably used with an old browser than only supports 8-bit charsets in its engine for regular expression: it should support it if it was using for example ICU inside its Javascript implementation (almost all other borwsers have integrated ICU, even those that are still not fully supporting more advanced HTML5 parsers or renderers, and various accessiblity and security features in HTML, DOM or Javascript). There's NO easy way to integrate a fast and reliable regexp engine rewritten in Javascript if it does not support Unicode regexps based on Unicode codepoints and not on isolated bytes of UTF-8 encoded sources, or if it still does not support UTF-16 in Javascript strings, and does not recognize non-BMP characters, or makes incorrect string normalizations or case conversions; there exists some polyfills, but they are not reliable or maintained, as there's almost nobody using such old non-conforming Javascript engine!
There are SO MANY sites that assume ECMAScript 6 to support Unicode, and a very vast majority of the web now uses Unicode everywhere (and Mediawiki has this support required since even longer, and will no longer port anything for old browsers, or old servers or old databases that still do not support it after more than 20 years!). SeaMonkey is then a dinosaure (just like old Internet Explorer with all its tweaks and bugs, but at least the last supported versions of IE had full Unicode support and ES6 requirements for regular expressions).
For what it's worth: https://www.lambdatest.com/web-technologies/es6-support-on-firefox-60
Firefox 60.8 being the engine of SeaMonkey, and bugs aside, ES6 is supported.
I don't experience weird things on this site. They do fix the worst bugs for the time being. I've compiled SeaMonkey against my system libraries, not the bundled ones, including ICU.
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)...
As a side note: you are free to code in any version of JavaScript you want, but there is a user in this thread who thinks it should be ES6 compliant. Don't listen to him, because that would mean you will have to fix it to support SeaMonkey, as we have to regard the opinion of lambdatest.com and Mozilla more than anonymous user 'Verdy p' of translatewiki.net.
I am not anonymous. And I'm one of the oldest contributors of translatewiki.net, and have made lot of maitnenance work and support for helping many languages to startup or develop themselves, and added many missing documentation. But this site is not the support or developer site for any webbrowser. Translatewiki.net is an open project, and like all projects (free or not) it has limitations, most of tham based on available resources in humans and the time they can contribute, plus technical skills needed and sometimes money for the infrastructure. Most users here (including admins) are not paid for the work they already do for you and for all others since many years, as a best effort only, but without any contract with you. You are free to contribute, but if you can't, don't blame others if they can't help you more, when they explain their limits and propose you possible alternatives than most users accept without problem and that are available to you. If you don't like these alternatives, then there's nothing more we can do.
That's a fact that SeaMonkey does not support ES6 regexps (no support for non-BMP characters, it only supports "character classes" where characters are single UTF-16 code units, and treats non-BMP characters only as a pair separate "surrogate" code units, which count for 1 "character" in regexp character classes; as well no support for "\u", "\p{}" and "\P{}" and the "\U" flag, which are part of ES6): https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla/-/blob/2_53_14_final/js/src/irregexp/RegExpEngine.cpp
You should ask to SeaMonkey developers/support for such extension and revision of their regexp engine (note that SeaMoneky already has optional support for ICU, but it is not used by its regexp engine). Without it, transforming regexps is not evident: e.g. transforming ES6 regexps like /😀+/ or /[a😀]/ is not trivial: without ES6 support for unicode codepoints (not code units), these regexps will match more things than expected. The same affects regexps that would contain Chinese characters in the supplementary ideographic plane, or any attempt to match words written in Shavian, Deseret, and some modern scripts like Osage, Warang Citi, Adlam, Wancho and Toto, or existing MediaWiki translations for Gotic Wikipedia.
It's up to participants and supporters to the SeaMoney project to ask for ES6 compliance and help there if they can. But if they don't this is not surprising that this webbrowser is not even listed in https://caniuse.com/?search=es6 and that the browser has low usage. (non-ES6 browsers include IE11, and Opera Mini, bith of them also having limitations on this site, and IE11 is even no longer supported; Opera Mini remains only inside some old cheap smartTV's an a few appliances that should also not be used with Translatewiki.net). We don't really need all ES6 features in MediaWiki, but MediaWiki now depends on more and more components that need it (some support may still be present to emulatewhat is missing but it will be either slow or limited, and it is normal for these wikis to inform users with messages about things that do not work and that are not working, and will likely not work soon if this requires heavy development and tests, and constly maintenance that current developers have no way to support for long when they have many more things to do, fix and maintain elsewhere).
Side note 2: Mind the insane edit and re-edit history of this thread.