Solutions to WikiTree's language problem. How to proceed?

Question

This is a follow-up to my earlier post on how to address WikiTree's lack of a multi-lingual user interface.

Thank you all for your thoughtful and insightful responses to my previous post. The proposed solutions seem to fall into 3 categories, which I have tried to summarize with my thoughts below:

---

1. Rewriting the core WikiTree software from scratch

Pros: Given the comments from Edison, Dennis, Jamie, and Jim, this sounds like the best long-term solution. It would offer the most flexibility, solve other problems, and could result in a system that would be easy to update and extend. I am convinced that this will need to be done at some point, and sooner would be easier than later.

Cons: Massive coordinated software development. Would likely take years to complete.

---

2. Expanding the utility of the WikiTree browser extension

Pros: Less software development, while still offering a substantial amount of flexibility. Could likely be completed in a more reasonable timeframe. (several months?)

Cons: Requiring a browser extension in order to use basic features of this site still presents a barrier to non-English speakers. Prior to the responses on my previous post, I (an  English speaker) was only vaguely aware of the browser extension, and I did not know what benefits it had to offer.

Furthermore, even if the browser extension perfectly translates every element of the WikiTree user interface, we have simply moved the language problem. Either the user interface of the browser extension must be multi-lingual, or static help pages describing how to install, configure, and use the extension must be translated into multiple languages and maintained as the extension evolves.

Either way, the benefits of using the extension would need to be featured front-and-center during the sign-up process for new users, ideally via an initial language selection menu which would redirect to a static instruction page in the user's native language.

---

3. Third-party translation tools (built into modern browsers, e.g. Chrome, Safari)

Pros: Requires no software development. Non-English speakers can (and likely do) use this software today.

Cons: While third-party translation tools have improved substantially in the past few years, they are still not perfect. WikiTree has little to no control over how these tools behave, and would not be able to correct cases where translation fails.

Like with a browser extension, requiring third-party software in order to use basic features of the site still presents a barrier to non-English speakers. Help pages describing how to use these third-party tools must be translated into multiple languages, and maintained as these tools change. Again, these help pages must be featured front-and-center during the sign-up process for new users, ideally via a language selection menu.

---

None of these solutions are perfect, and each of them have their own advantages and disadvantages. A complete code rewrite would ultimately be the best long-term solution, but Jim's comment that "perfect should not be the enemy of good" is also important to keep in mind.

How can we decide which solutions we will pursue, and what to prioritize?

What actions would be needed to move each of these three projects forward?

Would love to hear people's thoughts on this.

Comments

Thank you for this great summation, David. I hope we'll hear from the Team on what the way ahead can be, including responses to Dennis's and Edison's points on the earlier thread.

---

thank you for your contributions david. A note on option 3:

The help page for the translation in Chrome is available in many languages and being actively maintained by Google.

---

David, your ability to focus on this problem and organize all the stuff that was thrown out in the response to the original question into coherent options is truly awe inspiring.  This post is nothing short of magnificent.

I have a note on option 2 - if WikiTree ever gets to the point of requiring use of a browser extension, I will not be able to remain a member because I do not - and am not willing to - use any browser plug-ins.  Aside from a probably minute number of people who feel as I do, I don't know what browsers are supported by the extensions and would guess that there are people who use browsers for which there is no extension available.  To attempt to identify (and port the extensions to) all browsers used on all operating systems, and then support all these versions of it, would be a monumental task all by itself.

---

Gail, I’m with you.

---

WikiTree has taken significant precautions for the preservation of its data, and publicised them well so that members can be confident in them. However, as points raised by David, Dennis and Edison show, it is not so easy for members to have the same degree of assurance that the future of WikiTree's software is sound.

Perhaps there are already plans to cover these issues which can be summarised for us. If that is not yet possible, could the Team please let us know a timeframe within which answers for these important questions will be able to be provided?

---

I have complete confidence that the future of WikiTree's software is fine. That's why I use it as the main place I publish my genealogy research.

While Edison pointed out we are using an older version of PHP, he neglected to mention that it is not a version that was used when the site was created, which means that it can and has been updated (and continues to be updated when needed). Brian is very careful about making sure the site is secure, it is running on hardware that can support the data and site usage, and most importantly, that we don't add anything that is going to skyrocket the cost of running the site, so it can continue remaining free.

---

Thank you, Jamie. That is encouraging, though it would also be good to know of plans to address other components of Edison's larger picture, specifically MediaWiki: "operating forever on deprecated scripting interpreter engines (i.e., PHP and MediaWiki, possibly MySQL eventually) isn't tenable."

More urgently, how can a multilingual interface move forward? Wouldn't there be value in an effort to publicise the approach of translation within the Chrome browser, for example by providing a short WikiTree Help page in multiple languages? A pointer to the Chrome help page could be sufficient, provided it was prominently visible to potential new non-English-speaking members and had a note that there is a selector at the bottom of that page to choose the display language.

---

I did address Edison's worry -- PHP and MySQL get updated as needed so it's not "operating forever on deprecated scripting interpreter engines". The version of MediaWiki doesn't matter since it was just a starting point and again, most of the features of WikiTree are not stock MediaWiki code (anything with privacy, anything having to do with relationships, messaging, comments, search, any reports, G2G, etc etc, even stuff like categories have been re-written from scratch). So basically: it's not a big deal if things aren't running on the latest and greatest versions of software. The site is secure, it is fulfilling its mission of being a free shared tree site, and will continue to get new features and be updated.

Doesn't the translate option just pop up in Chrome whenever you visit a site that isn't in your default language? (It's been doing that as long as I can remember). Does anyone know how it works if your default language is something else?

---

Thanks again, Jamie.

I don't use Google Chrome and I'm not sure of the answer to your question about it. I hope Jimmy Tree will comment.

But whatever the answer is, my point is that it would encourage the participation of non-English-speaking people if WikiTree developed a Help page with a short segment but in many languages, mentioning that translation within the Google Chrome browser could help them to use the site.

---

Being an international user i allow myself some remarks:

For true internationalisation one must consider the following area's, assuming that on your 'self' page you can set your national preference.

1. plain text information/help files is easy and (partially) implemented. Example the 'Nederlands Portaal'. I assume something similar exists for other languages

2. Profile form/menu: is normally dependent language and geo location. E.g. 'middle initial' field is only used in North America. Germanic languages can have text preceding the surname (the preposition'). E.g. in my name 'van der Burg', the 'van der' is the preposition and 'Burg' is the surname intermedia. Many Dutch surnames now fall under 'V' iso 'B'. Many US

3 Profile form/menu layout can also be language/geo location dependent.

The closer the UI resembles the local habits, the more international people will embrace Wikitree.

Answer 1

Not to sound glib.... but why not do all 3?!

Or, at least 1 and 3.  As 1 is long term for WikiTree 2.0... 3 is now!

Danke!

Gracias!

Go raibh maith agat!

Answer 2

Great sum up!

We, as the community here, can only advise. Option 1 is what is needed, but only the owner of the site can decide that. Many times, the investment (time, money) aspect has been brought up as a no.

The way to develop 1 is to separate out functionality and transfer that to smaller units which you can develop, test and use in a reasonable time.

So the pragmatic approach, or how we do this in an Agile development is to see what brings most value for the users (assuming the business of WikiTree is about attracting the most users possible). To me that is in using option 2 in the short run and do a slow burner on one.

Option 3 is already present and does not solve the issue at stake: people with hardly any computer experience should visit our site and are hindered by the language issue and overly complicated user interface. Those people, nearly all of my relatives, will not use a browser extension nor the auto-translate.

Another reason I don't like the third option is that no one can be sure what is shown where once some big external company decides to change a translation. A maintenance nightmare is very near then.

Comments

Thanks Michel. I think option 3 has greater potential than you do, but I agree on your other points.

For anyone wondering, Atlassian describes Agile Software Development as follows:

Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly. *

See also Wikipedia.

* Short extract of Atlassian-copyright material provided for informational purposes under fair use.

Answer 3

Thank you for your analysis.

Not that I would need it, since I'm an anglophone, but the browser extension wouldn't work for me. I refuse to use Google products or services, because Google spies on everybody and then sells the information to advertisers. It's like gossip, except their motivation is money rather than trying to make themselves look good by exposing the foibles of others.

And, since Chrome is far and away the most popular browser, it make sense to program an extension to work with it. (There are hardly any extensions for iCab, which is my favourite browser, because it has such a small user base.)

So anything that depends on Chrome, and only Chrome, is off the menu for me. (Or anybody else who doesn't want to use Chrome, for whatever reason.)

Comments

Greg, the WikiTree browser extension works on Firefox, Opera, Edge, Brave, and Vivaldi, as well as the Google Chrome browser.

People who do not speak English may find that the utility of in-browser translation offered by Google Chrome outweighs your concerns.

---

There may be a misconception arising from the statement that the WikiTree browser extension is (as well as for Firefox)

• For Chrome browsers (including Opera, Edge, Brave, and Vivaldi)

It would be better if this said

• For Chromium-based browsers (including Google Chrome, Opera, Edge, Brave, and Vivaldi)

See this link for an explanation of the distinction between Chromium and Chrome.

Answer 4

Hi

To point 3: I'm in the team that translated (and still is) the English help pages to German. We used DeepL a lot, as it is way better than Google translate. But still, there were many translations from DeepL that were not correct, as genealogy uses terms that are not always the first "one to one" translation (eg. family tree is not the same as pedigree, while German has only one word for this). So useing a browser translation system might very well go wrong and not be as helpful as it might seem at the first moment.
Also, I'm against Chrome, as in this case Google can be avoided very easily.

Answer 5

If solution #1 is ever used I'd be happy to help translate anything needed into French (I don't have the technical skills to help otherwise, though)