WikiTree has a language problem. How can it be fixed?

Question

WikiTree does not have a multilingual user interface. This presents a significant barrier to ~80% of potential global WikiTree users. A quick search through previous threads brings up the following:

"I agree it needs to be multi-lingual, I know more than one person who would have participated if it had been, but being only in English, they abstained."

"I know a very experienced genealogist who was put on moderation and left WikiTree because he thought his efforts were not appreciated, whereas it was all simply a case of Lost In Translation."

I am aware of the Language Portal projects. I do not want to dismiss the efforts of the multilingual WikiTreers who provide assistance to non-English speakers, but the fact remains that the user interface to perform even the most basic of genealogical tasks such as "add parent", "add child", or "add spouse", is available only in English. Surely these most basic elements of the user interface could be made available in multiple languages? It would go a long way towards making this site accessible to everyone.

I understand that this site is a fork of a legacy version of MediaWiki which did not include multi-language support. That is unfortunate, but it should not be an excuse. This problem was raised as far back as 2015, and many times since then (2016, 2017 Jan, Apr, Nov 9, Nov 24, 2020, 2021 Jan, Aug). It is now 2023, and the WikiTree user interface should support multiple languages by now.

The value of fostering a diverse community cannot be overstated. If we really are building One Global Tree, this problem will need to be dealt with at some point. The sooner this problem is addressed, the faster this site will grow.

What actions can be taken to address this?

Edit: Thank you all for your thoughtful and insightful responses! I have posted a follow-up here.

Comments

Thank you for ably drawing attention to this crucial need again, David.

Reliance on an old MediaWiki version inhibits progress on many other fronts as well. Given the success of collaborative programming in developing the new multipurpose WikiTree Extension, the same approach could be considered for wider application.

A medium-term project to redevelop the core WikiTree software from scratch, involving members with software experience from outside the Team and based say on a GitHub repository with suitably controlled access, would be worthwhile. A first step would be examination of scope: what should be re-implemented, what should be altered, and what new features (like a multilingual interface as you propose here) should be built. An important goal would be that the resulting system would be easy to update and extend, without the limitations of MediaWiki 1.11.0.

---

Great idea Jim. But before that, we need to bend the heads of the team and the owner of the website: Interesting.com

This is work in progress with the creation of the add-on that can change the interface drastically. See https://www.wikitree.com/wiki/Space:WikiTree_Browser_Extension

---

Michael, I recently installed the browser extension.  Your comment inspired me to look further into its features.  Thank you.

---

Given the success of collaborative programming in developing the new multipurpose WikiTree Extension, the same approach could be considered for wider application.

My experience with the extension makes me think that we wouldn't be ready to do a larger project yet. With the extension, every feature can be turned off or on so there is a lot of freedom for the programmer to do what they want and add whatever feature they fancy. That wouldn't be the case for the core of WikiTree -- I expect there would be a ton of disagreement about what should be included and how things should be implemented.

Also if this were to happen, it definitely wouldn't be based on MediaWiki. 

---

But could an app/extension be developed that would support different languages?

---

It did come up as a possible feature for the shared browser extension during Hacktoberfest, but no has implemented it yet.

And anyone could do work to translate the different views in the dynamic tree/tree apps into different languages.

---

I agree that the replacement shouldn't be based on MediaWiki: it should be developed from scratch.

I'm sorry to hear that Jamie thinks disagreements would be an issue. While WikiTree members good at software would no doubt make many proposals, as always the Team would make final decisions on direction. From that point, there'd be a lot more programmers available to write parts of the code, which of course would need to be approved by a Team member before entering the live system.

---

If the English language items coming out of MediaWiki would be set as fixed (non-changeable) items, it shouldn't be too hard to add a translator function to the extension. A lookup table, maybe tweaked with location of the text item...

For software team management: disagreements will always exist. My short advice: separate the 'how' from the 'what'. I'm no front end dev and have little time, but if someone would like to discuss/reflect on the project management: send me a pm.

---

Follow up G2G has been posted

https://www.wikitree.com/g2g/1526892/solutions-to-wikitrees-language-problem-how-to-proceed

Answer 1

David,  I have had both hands firmly clamped over my mouth  in order to prevent my foot from getting in since right after you posted this superb question.  This response is likely to get a whole lot of downvotes, if not flagged and hidden for not being able to say things as nicely as you did, but I just can't keep silent any longer.

Jim's comment (why, oh why wasn't it an answer that could be upvoted and would carry more weight?) with a constructive and realistic proposal for a way to cure all WikiTree's shortcomings is an action that certainly can be taken.  I think that the real question is whether it ever will be taken.

I would be shocked if anything like that is ever done, though.  Having been a member since 2014, I saw all those instances when this topic was brought up in real time.  I didn't look at the links, but probably participated in some of those discussions.  

A long time ago, I formed the opinion that the admin team wants to have their cake and eat it.  They seem very motivated to grow WikiTree - that is, members and profiles, but that creates a conflict - prospective (and new) members are turned off if there are controls intended to protect the integrity of our profiles, yet they also express desire for our tree to be accurate.

This result of these conflicting motives is two mutually exclusive things:

• We see many posts by new members complaining about not being able to upload a gedcom and instantly have it populate the tree with a bunch of duplicates, unsourced profiles, and all kinds of untruths.
• There are also many posts complaining about the numbers of profiles that are unsourced, with empty biographies, and all the "gedcom junk" resulting from shortcomings in the import process.  

The team's solution appears (to me) to be having all kinds of fun-and-games thons and challenges and what-all to get the active members to buy in to spending all kinds of time fixing all the bad things in profiles.  Many profiles get fixed during these events, as well as by members who don't participate in the marathons, but quietly plod along fixing things because they care, rather than for the prizes, points, or whatever other carrot may be dangled in front of their noses.  The dilemma is that, despite having more events and more participation that results in increasing the number of fixed profiles each time an event is held, the number of profiles on the "bad" lists (unsourced, no biography, gedcom junk) keeps growing because the rate of new member signups also keeps growing.

The rigidity of name conventions is another problem that raises its ugly head often in G2G.  The team has agreed, in principle, that names are not handled as elegantly as they need to be, but also listed chapter and verse of the  technical difficulties of changing how names are handled.  While I am fully aware of the technical issues, I think it is imperative to make the needed changes, but my impression is that the team will never open this can of worms.

The language issue is just another sticky wicket of contradiction.  The team has stated that a goal of WikiTree is to be truly international, but my impression is that their head is in the sand, thinking that having language teams of members who put in a huge amount of work translating help files to a few other languages will solve the problem.  The number of languages needed is at least several hundred and I fully agree that it is needed across the entire site.  Telling us to use Google Translate is not a solution - their butchered translations leave way too much to be desired.

OK - I'll get off my soapbox now, and hope I don't get thrown off WikiTree completely for having been too critical.

Comments

Thank you Gaile for these valuable, wide-ranging, constructive, impersonal and purposeful points!

---

I started to write things a couple of times, but deleted them all.

Your reply, and Jim’s, are both well thought out, making valid points.

---

The team has stated that a goal of WikiTree is to be truly international, but my impression is that their head is in the sand, thinking that having language teams of members who put in a huge amount of work translating help files to a few other languages will solve the problem.  The number of languages needed is at least several hundred and I fully agree that it is needed across the entire site.  Telling us to use Google Translate is not a solution - their butchered translations leave way too much to be desired.

So relying on teams of volunteers to translate isn't the solution, but automated translations are also out -- so who exactly is supposed to translate the hundreds of languages you say are needed, and continue translating as whenever there is a change to the UI? 

Also, WikiTree isn't just a piece of software, it's also a community (that's why I eventually settled on WikiTree after a few years of using WeRelate and FamilySearch). Events to get people working together are part of that community, but that's completely separate from the tech side. And the community-wide stuff is always going to need to be in a common language -- unless there are volunteers to run parallel discussions/live chats/etc.

Re: Jim's comment above about "A medium-term project to redevelop the core WikiTree software from scratch" -- this has been discussed before amongst the team. I know some people like to give their "impressions" that the team isn't aware of the current limitations and problems with the site, but we use the site for our genealogy too. We are just more realistic about what can be done with the resources available. 

---

My hope is that the resources available can be dramatically increased by expansion of the successful model which built the Extension using WikiTree members with software experience from beyond the Team.

---

My experience with the browser extension would indicate that it would require more resources (aka man-hours) to manage a group of programmers of different backgrounds and experience levels than just doing it in-house. Coming up with standards, speccing out requirements, making sure the code doesn't conflict with other code, making sure no one adds code that's going to crash the site/cost a ton of money to run, testing, writing documentation, that's all stuff that needs to be done that people generally don't want to do (especially as volunteers).

So it's great that there are people who want to code, but there is a lot more that goes into creating software than just coding.

---

So what eventual solution could be feasible? The longer time passes, the more the need for a complete redevelopment will grow, as demand for new features impossible with MediaWiki extends, and old code becomes increasingly outmoded or even insecure.

At some point the status quo will become untenable. I suspect dealing with that will be more difficult later, not easier, because there will be more existing code to deal with as a result of piecemeal additions in the meantime.

---

Do you think the MediaWiki code hasn't been updated with security patches? Just because it hasn't been updated to a newer version of MediaWiki doesn't mean that code hasn't been altered. Most of the features of WikiTree aren't MediaWiki code.

as demand for new features impossible with MediaWiki extends

What features are those? 

---

A multilingual user interface is one, apparently. See David's question above.

Also style notifications.

---

Another one impossible with 1.11.0 (according to discussion in November 2021) is sort keys for tables.

---

Who said it was impossible? Even if we were on a completely up-to-date version of MediaWiki, most of the text on the site is not from MediaWiki, so we would still have the problem of who is going to do the translating.

And translating the interface would just make it easier for people to add data to the site. They still won't be able to easily participate in events, participate in discussions about policy, get help if there is a problem, collaborate on profiles in other languages, etc without someone doing some translating outside of the UI somewhere.

Edit: It seems as if you are using "impossible" to mean "not built into the version of MediaWiki WikiTree uses". So yes, it is impossible to get those features using the default install of MediaWiki. But by that standard, privacy controls, finding the connection between any two person articles, importing data from GEDCOMs, managing articles, etc are all impossible.

---

Re your edit: Right, the examples I'm giving are based on that meaning for "impossible". Another request was for a newer version of the Cite extension; again the old MediaWiki was said to be the impediment.

On your second paragraph, people from different language backgrounds participate well in discussions and exchange of help already, with either them or another person using machine translation before posting. There already exist profiles in different languages. If we had a critical mass of people from such language groups, collaboration among themselves would work well.

Let's not make the perfect the enemy of the good. WikiTree cannot maintain that its goal is a worldwide tree if it won't even move towards a multilingual user interface.

Jimmy Tree's excellent insight is that the Chrome browser can do quite adequate user interface translation. So maybe we can go forward on that now, and again leave eventual wholesale redevelopment as an unresolved challenge.

---

Jamie, I have long been curious about whether there is some grande vision or long-term master plan for the site that describes where the team thinks we should be or will be in, say, five or ten years?  What'll be new and different?  If there is a master plan, could the highlights be shared with the members, even if it differs from what current members say they want?

I think most of us understand that long-term plans often take longer and cost more than expected, and get modified and tweaked and fine-tuned along the way, and that the goal posts sometimes move.  But if there is no such plan, then it seems the plan is to limp along in a reactionary mode until the house starts to fall down around us.

---

Thank you Dennis, Gaile, Jim, and Jamie for your insightful responses. I am convinced that a complete code rewrite would be the best long-term solution, but without knowing what The Team's long-term plans are for this site, I am unsure how to proceed. I have posted a follow-up with my thoughts here.

Answer 2

My proposal: Wikitree should implement several changes to make the site more user-friendly and global. These changes do not have to be all at once. But I do believe that instituting these changes and showing Wikitreers that Wikitree is committed to globalization, will go a long way.

1. Provide a button that will swap LNAB and given names, so that Asian/Hungarian style names will display properly.

2. More language portals and parallel categories.

3. Language interfaces (my suggestion is a minimum of Mandarian, Arabic, French, Spanish, and Hindi).

4. Last, but not least (but by far most labor intensive) Wikitree needs Mentors, Project Leaders, and genealogists from different cultural backgrounds, including various indigenous communities. There is no "one size fits all" solution for naming, what counts as a LNAB, and cultural sensitivity. It's only by collaborating with people from these cultures that Wikitree will be able to move forward in a sensitive, accurate, and global manner. Contacting and bringing these people into the Wikitree community will not only be a task the Leaders will need to work on, but those of us in the general community as well.

Comments

Jessica, I fully agree with everything you said except about naming.  There is a one-size-fits-all solution for names.  It was proposed in G2G by a member about 4 or 5 years ago.  I don't have that post easily findable, but will try to locate it and add a link to it here if I find it.

The gist of it is that we have only 1 name field, which would be paired with a new name type field and a display order field.  You could put as many or as few name fields on a profile as you need.  The name types would be selectable from a list such as:  first name at birth, current first name, other first name, LNAB, current last name, other last name, middle name, patronymic, prefix, suffix.  The display order would be selectable from a list such as:  0, 1, 2, 3, 4, etc., where 0 would be to not display the name field content as part of the profile title or anywhere else the person's name is displayed.  Of course, all name fields would be displayed in the data section of the profile.  In addition to being able to handle all cultural naming conventions, past, present, and future, this has the advantage of not causing the software seismic event that any other name solution would because of the way LNAB plus hyphen plus a sequential number is used as the unique identifier for profiles.

---

That sounds like a suggestion I made. Was it really that long ago?

---

I don't remember the last name of the member who offered that solution, but I think his first name was Patrick.

Answer 3

Translation tools have become really good, to a point at which manually translating websites is almost hard to justify.

Chrome has it included via right click on a page and can also remember setting for a given language, so that it always translates pages from a certain language to your native one.

Here is this discussion in japanese.

Here is justin trudeau's profile

Have you tried showing this to people who struggle?

Comments

Jimmy, David is not talking about the content of static pages like displayed profiles or help, but the user interface: field names and instructions on dynamic pages such as the search page or profile edit tabs. There's no value in using automatic translation there: the resulting page would not be dynamic, or even on the WikiTree site, and you wouldn't be able to do anything with it. You can't reply to this discussion at the Japanese link you posted.

Try applying Google Translate to this link (the edit tab for Ben Franklin-1):

https://www.wikitree.com/index.php?title=Special:EditPerson&u=388

It won't get you anywhere, because Google Translate cannot login to Wikitree.

Edited to add: In this comment I was talking about non-integrated Google Translate for websites. At first sorry Jimmy I missed your point that the Chrome browser can dynamically do translation within a web page you are looking at.

---

The translation feature that is integrated into Chrome has the same quality of translation, AND all buttons remain usable. I have difficulty choosing a language for the demos I post, because I doubt there is a language besides english that makes any sense for more than 5% of the people here.

this is the edit page of Benjamin Franklin in Esperanto 

this smaller screenshot might scale better on other displays

---

Jim, I think the links Jimmy has given are just examples of what is possible since he can't share his specific machine display.

But the method he mentioned for right click > Translate keeps you on the same page and you can interact with (log in and use the site) as normal.

In fact, I frequently use this method to translate WikiTree into Czech. Many of my older extended family can speak  some English, but can only read in Czech  - so I can easily log in, right click > translate to Czech, and they can now view the site with me as well as the family genealogies I am creating.

---

In comment of actual WikiTree translations - yes, we all know that machine translations are not the best (though they are getting better). In order to do full translations of the site, we have to first come up with the method and the resources. 

Would we do the Wikipedia way and create language subdomains? That would mean custom building the different language sites to all interact with the same databases and input. That could be troublesome...

Or would we implement language files? Language files would really be the best way to handle this - but this comes with a whole host of other issues, specifically developer availability, translator availability, etc. Aleš has worked on a translation system, but in my opinion that has largely failed because of not enough volunteers available to do the translations. And each time the site changes, those translations have to be revisited and updated, which means a lot of the information gets out of date with new development releases, community changes to policies, etc.

...the user interface: field names and instructions on dynamic pages such as the search page or profile edit tabs.

If this were truly be efficient and not a burden to WikiTree itself, I think this is something we can and should explore through the WikiTree Extension. Since the files are hosted on GitHub, anyone could jump in and assist with translations very quickly.

---

thank you for phrasing my thoughts more eloquently steven

---

Hmm, thanks Jimmy, that method does look interesting. I don't normally use Chrome, but I tried it, with an edit tab translated into French. It partly worked, though there was one odd error message when I tried to discard a draft. It seems worth investigating as a possible approach. Maybe people who would like to edit in other languages than English could try it out more thoroughly, and report back.

Edited to add: Steven, have you successfully edited and saved pages with the edit tab translated into Czech?

The quality of the translation is not too crucial if we're just talking about short field descriptions like "Last name at birth" or "Birth Place". Some of the more complex instructions might get garbled.

Safari can translate on the fly too, but it translates the field contents as well as the interface: that would be disastrous.

---

Edited to add: Steven, have you successfully edited and saved pages with the edit tab translated into Czech?

Yep. Inputs are not forced to translate, just the static text. Again, the translations are not always the best, but it commonly understand what is intended when you are able to view all of the fields translated.

---

That's encouraging. It could be worth developing an official Help page detailing how to use Chrome in this way, and then making versions of it translated into as many languages as possible, maybe using automation plus fine tuning. This should be feasible for just that Help page; afterwards, non-English-speakers might be able to do a great deal more.

---

Thank you, Jimmie, Jim, and Steve, for this discussion.  It's great to hear what can be done, despite the limitations of the system.  Thank you for your  positive approach to this problem.

---

A help page like that can be found here. The language can be changed in the url (replace the last two characters "en" with the familiar TLD abbreviation, eg "fr", "es", "pl", "jp") or at the bottom of the page.

---

Thanks Jimmy, that's again very useful. It could either be used as the basis for a series of multilingual native WikiTree Help pages with notes specific to the system here, or just be linked to from a brief prominent official WikiTree Help page. Steven: could the Team please organise something like that, if necessary after a bit more checking that there aren't any snags?

It's great that after the saga of requests for a multilingual user interface going back to 2015 that David drew attention to, Jimmy has now pointed to a promising solution.

---

Jimmy, the help page you linked to suggests that the Chrome translation function is available only on iPads and iPhones (ie., only iOS). I saw no help text for other devices (laptops, desktops) or non-Apple devices.

---

That's odd, Jillaine. When I look at it (on Safari or Chrome on an iPad), it has three tabs you can choose from, with variants: "Computer", "Android", and "iPhone & iPad". Did you look at all three tabs?

---

Thanks, Jim. I hadn't seen those "tabs" -- clearly hadn't had my morning coffee yet... Once again...

---

Thank you Jim, Jimmy, and Steven for this useful discussion. Automatic translation tools have certainly improved substantially in the past few years, and they seem like a promising solution that could be deployed fairly quickly. I have posted a follow-up with my thoughts here.

Answer 4

I agree; at least some basic functional controls should be either multi-lingual or language-selectable in settings.

Though, I also agree there are more browser extensions to help and translate, and they are getting better, but something built-in would be more efficient and welcoming.

Let us...

Welcome!

Wilkommen!

Bienvenidos!

Fáilte!

Answer 5

"Also if this were to happen [updating the core of WikiTree], it definitely wouldn't be based on MediaWiki."

My personal opinion is that Jamie is spot-on with this observation. I think it's time to retire MediaWiki as the underpinning core application, and to very likely design one that's custom written for the purpose.

I'm not privy to any of WikiTree's operations, and I know that The Team are all well aware of the situation; so I'm not going to say anything new, and some of it may be incorrect (too, it's going to get awfully "jargony" and super boring for all you who aren't web developers). And we all know that keeping WikiTree free for all is a massive constraint to new development. But in my opinion MediaWiki was a handy, open-source option around which to build WikiTree initially, and in truth it's served the purpose admirably. However, after the heavy customization in WikitTree's first several iterations, I believe it became essentially impossible to update MediaWiki as that open-source software continued its own unique growth curve and refinements.

With that, I truly don't believe any substantial modification of the current MediaWiki core is practical; it wouldn't be terribly effective and certainly not efficient. One important factor there is that the principal operational interface--technically a hypertext preprocessor--between the code and the MySQL database(s) that store all the data is something called PHP. First invented in 1995, PHP is used in roughly 80% of all websites globally. That "engine" is also open-source software and managed by the PHP Group, which issues frequent minor releases and security patch updates to add features and improve resilience. In 2008, one of my own websites was hacked via a PHP vulnerability and rendered unrecoverable; the solution was to wipe it clean and install a previous backup.

WikiTree runs on state-of-the-art server and infrastructure systems at Amazon Web Services (this not including the fantastic work done by Aleš on WikiTree+, which processing I believe is done on servers in Slovenia). The hardware, networking, and server software (as contrasted with the core application software) is robust and maintained by AWS. That's not an issue.

The WikiTree core is MediaWiki v1.11, which was released 10 Sep 2007. The current MediaWiki production version is v1.39, released 30 Nov 2022. The last version of MediWiki to support PHP v7.1.x was MediaWiki v1.33, released 2 Jul 2019.

WikiTree uses PHP v7.1.33, the last minor release in the v7.1 branch. The major v7.1.0 release was made 30 May 2019, and v7.1.33 was released 24 Oct 2019. The PHP version in use at WikiTree reached end-of-life in November 2021, meaning that no more patches or security updates have been issued since that time. The most recent production version of PHP is v8.2.0, released 8 Dec 2022.

Given that we've been operating 14 months on a deprecated version of PHP leads me to believe that it simply cannot be updated to a more recent version without significant modification to the core MediaWiki code at WikiTree. Germane to the original question is that as of v1.36 of MediaWiki, released May 2021, it has required installation and use of the PHP internationalization extension (also referred to as just Intl, ext-intl, or php-intl).

WikiTree is also using MySQL v5.7.38. This is the database management engine that, like PHP, sits as an operational layer underneath the application code (MediaWiki and other) and above the webserver operating system. The major v5.7.x branch of MySQL was released 21 Oct 2015. It is still actively supported, but reaches end-of-life this October. MySQL major release v8.0 was published 19 Apr 2018; the latest version is v8.0.31, released 11 Oct 2022. I once created a MediaWiki v1.11 sandbox just to experiment with the core version in use by WikiTree, but long since deleted it. However--and with no level of certainty--I don't believe moving to a MySQL version later this year that is still supported would bring with it the same level of complexity as trying to move to a new version of PHP.

To be clear, there are no alarm bells going off about PHP v7.1.33 vulnerabilities, though some specific ones have been identified, mostly minor. That isn't the issue so much as the fact that trying to do significant modifications to core code that relies on that older PHP version would be a waste of time and money. And I believe, since WikiTree was built by directly editing MediaWiki code rather than with an additive/modifying module approach, that crafting it to enable use of current and future MediaWiki versions may not be in the cards--from a planning and design standpoint you'd need to, effectively, do everything twice: plan and design what operations/functions we need, and then plan and design it again in order to build it as add-on modules to MediaWiki that won't break with future MediaWiki releases. (Many types of content management systems--which is what MediaWiki is--like Joomla and Drupal moved years ago to fairly simple ways that PHP and CSS scripting overrides can be applied via server directories that remain unaffected by upgrades to the CMS itself, and MediaWiki can do the same...I just don't think it would be practical given the extent of the modifications necessary for WikiTree.)

Bottom line is I believe--uninformed personal opinion only--that operating forever on deprecated scripting interpreter engines (i.e., PHP and MediaWiki, possibly MySQL eventually) isn't tenable. Trying to shoehorn desirable and future-editable WikiTree functions and look-and-feel into a MediWiki core is also probably not tenable: basically double the work and MediaWiki would continue to be the least-common-denominator constraining future development.

The press for internationalization of websites is not new. There are various tools and services available to help accomplish this, at least to varying degrees. Sweeping language internationalization likely may never be possible, but of the more than 7,000 languages spoken in the world, over half the global population uses 23 of them; here's an interesting post from Berlitz a few days ago breaking down the numbers for the top 10. The distribution will differ considerably, though, among countries where genealogy is an active hobby and those where it's really not practiced (as we know it) at all.

But I'll bet heavily that engaging any of the popular internationalization tools or services is going to require a website that is operating on supported versions of its core infrastructure and application software. Bringing WikiTree up to date on these core softwares will have to be done eventually, no matter what. On the websites I have that are running on basic shared servers--unlike the virtual private server (VPS) that WikiTree uses)--they haven't permitted use of PHP v7.1.33 since November 2021; the hosting companies force the PHP change themselves as part of server management; if your website can't run on a newer version, it simply no longer runs.

The Lean Enterprise voice in my head tells me that you determine the root cause and address that, that you don't spend time and money fixing or responding to single-issue requirements or pain-points when the larger picture is what really needs to change. WikiTree faces resource constraints, but if planning for, say, a five-year lookahead window, those resources might be better applied to that big picture rather than firefighting incremental fixes and workarounds.

Comments

Thank you for this detailed, expert and cogent description of the situation, Edison. I second Dennis Barton's hope that the Team will give us an idea of what plans there are to deal with it.

---

Thank you for your thorough and insightful response, Edison! I definitely agree that a complete code rewrite would be the best long-term solution. I have posted a follow-up with my thoughts here.