Any sign of John Clause?
herrvigg opened this issue · 58 comments
It seems the qTranslate-Team is only 1 person and the author: @johnclause. Can you read us?
See also: #476, #538. He has not replied or given any sign of life for more than 1 year. I wondered if he even was alive but there is a short activity in dec 2017. So what is going on with this plugin? Is there someone who can get in touch with him?
It would be really great if we could know his intentions about this plugin which is very popular. If no answer this community should have enough good developers to make the plugin live from a fork or whatever as long as it follows the GNU GPL license. There has been some dicussions (see tickets mentioned above) but nothing is really moving to a clear direction.
Any other suggestion?
I've been thinking about adopting this and setting it up as a new version/plugin that supports all of the features qTranslate-X has now. I'd also like to recruit some others to make sure that this doesn't happen in the future. I use this plugin on a pretty well trafficked site and I've been making my own modifications to it over time to make sure it works for us.
Good idea, Colin!
I'm also ready to share my own modifications to this plugin.
Yeah, it would be good but are we allowed to launch our own version of the plugin?
Would you fork the current project or start a new project from scratch?
In the first case, it would be good to carry the current state with all issues and PRs. It could take a bit of time to review them but i guess it's worth. For instance there are already some big refactoring PRs and you keep all the history.
It the second case, you might have some regressions especially in the beginning. That's not necessarily the easiest to start with if you want people to follow from the current state of the plugin.
I was considering the same idea, since i run qtranslateX on a lot of sites and i don't like the alternatives i've seen so far.
So if you want to start a new supporting team count me in as a contributor. I also think we should contact the creator of https://it.wordpress.org/plugins/acf-qtranslate/ plugin (and other integration plugins) to see if we can collab together.
I think also this plugin https://it.wordpress.org/plugins/qtranslate-slug/ should be natively integrated in "qtranslate2018"
@herrvigg I would vote for the first situation. We can also notify John and get his blessing if he can not continue. This has happened before when qTranslate became qTranslate-x when it was taken over from the original creator.
@mayaliny definitely. I didn't want to overstep as I know many use the plugin and have contributed to it but I think making this an open collaboration benefits everyone.
Sounds good!
Also, be ready for a huge mess with Wordpress 5.0 which will replace TinyMCE with Gutenberg. This is probably going to have big impacts on qTranslateX. I hope version 4 can still survive for a few months, the transition is going to be quite heavy for many plugins (Wordpress is quite a messy framework).
@colinloretz I'd be really interested to see what your fork looks like now. There's no reason we couldn't open PRs and close issues on a fork so some progress could be made, no?
This plugin is the simplest and most intuitive solution out there, I really don't want to have to switch over to using WPML or Polylang after this 😞
I'd love to help this project if I can. So glad someone is talking about it. Any news? Also worried about wordpress 5.0!
@benjibee @janeschindler + all: I'm still running on the latest version but there's a lot of cleanup and support that is going to be needed going forward.
I've messaged the contact form on https://qtranslatexteam.wordpress.com/ and we've posted here to no response so I think it's time we start to discuss how we want to proceed with a new fork.
I think we should start a new project and release it immediately with the actual code (updating the "tested with wordpress version [latest]") and start gather new installations.
Then we'll work on this forum to suggest people to switch to new version (which would be only download turnoff/turnon thing)
Once we got that, and a multi author staff, we can work on new version (i'd prefer a solid compatibility with wordpress against new features).
Maybe I'm not the best php programmer out there, but i know some stuff and I can donate some hours per week to this project, so please, let me know.
PS- I suggest some names here, just to start discussion: openQtranslate, qTranslateXXL (i'd prefer the first one, but maybe the second is more effective when moving people from old plugin to new one)
Ideally it would be nice to be able to maintain this repository and keep the name with a new major version going forward. I've contacted Github and will reach out to WordPress as well to see if there is any known procedure for this.
If not, we'll have to do as suggested above and start a fork with a new name and move forward. There are pros and cons to each, for sure.
Any news from github?
Thanks for reaching out to GitHub Support!
If you haven't had any success contacting the owner, I'm afraid there's no other way to take over the project. Your best bet would indeed be to fork the project and continue development in your fork.
If you'd like, we can detach your fork from the original repository so that you can start over in a new network without being shown as a fork of the original?
Let us know if this is something you'd like to pursue, or if you have any other questions!
I think getting any new / continuation of the project will find its most difficulty being listed on WordPress plugin page and avoiding user confusion and plugin mismatches.
I think when Qtranslate which eventually became QtranslateX, the small name change was a good idea. It made a clear line in plugins and names where the new group took over and compatibility and searching for addons to it became easier.
QtranslateX2
QtranslateXtc
QtranslateXce
QtranslateX-CE (Community Edition)
That way any plugins additions have a clear demarcation on when / what they were developed for.
Just an idea.
Agreed. I like the name openQtranslateX, as suggested above. No matter what name we use, we need to write up some documentation that explains what happened to Qtranslate-X and a roadmap of what is to come.
I think the WordPress plugin gatekeepers will be more open to marking the old version as abandoned and link to the new plugin page. I can reach out to them when we are ready.
I think no matter what the name will be (even if the right naming will simplify the user moving to the new plugin) we need to move quickly to a new space/plugin.
That because the plugin is currently marked as "abandoned" from some security plugins like Wordfence.
After we have rolled up the new plugin we can send some press release to tech blogs to inform the community there's a new boss in town ;-)
I'm just a regular user (and pretty new to WP at that) but I've been using qTx for a website I'm setting up. It really is an awesome plugin and there's nothing out there that compares. But it has been very frustrating not to have a community to turn to when I hit a brick wall or even developers to take on paid projects when need be. I would love to see a fork come out. You have my support, albeit moral ;)
The sooner the better.
The question of the name may sound a bit futile but it's important to find a good name now because it's very hard to change later. My two cents: keep it simple!
Historically, qTranslate-X was derived from qTranslate which was already open source. Everyhing already being open source, I don't see the point of prefixing with open in the name.
Also i would rather rebase the name from qTranslate rather than qTranslate-X to not make it too complicated. No need to carry the whole history in the name. People looking for qTranslate-X should find anything based on qTranslate quite easily. All the details can then be described in the description of the plugin and on the new git repo.
Also, the author of the original of qTranslate was Qian Qin aka chineseleper. He even participated to qTranslate-X, certainly one of its main developer. Maybe we should contact him as well, he should be of great advice to continue on this project. He has a page on wordpress but has been inactive for 3 years. There were also two other developers on qT-X.
Here is the list of authors found on qTranslate-X readme:
Developed by: qTranslate Team based on original code by Qian Qin
Contributors: johnclause, chineseleper, Vavooon, grafcom
@herrvigg I agree that the whole history of the plugin does not need to be represented in the name. As such like abclution suggested (with a slight change) I think "qTranslate-CE" is very good and makes the most sense.
Keeping "qTranslate" in the name certainly is a good idea but the suffix "-CE" needs some translation/explanation ... why not using the prefix "Open" to emphasize the open character of the new plugin? I prefer OpenQtranslate above qTranslate-CE I have to admit ...
Well i don't really see the point of adding "open" to a public github repo, it is open-source implicitly as any public repo. The link to the repo should be very easy to find once the plugin respawns. I didn't come up with it, but CE makes more sense to me because we, as a community, are trying to resurrect it. Indeed it could also be something like qTranslateRebirth or qTranslateNeo. I won't diverge on a more religious theme ;)
I don't really care about what the name should be, in this phase.. i think we should hurry up to re-animate the code, no matter the name.
Although i think the string "qTranslate" should be absolutely present at least at the beginning not to confuse people about what the aim of the plugin is.
how are we with the fork thing? can we go for the "detach fork from the original repository" as suggested by github to @colinloretz ?
@colinloretz would you follow this operation for all of us?
@mayaliny we can have them disconnect it when we're ready.
I can get the new fork going and add some guidelines for contributing and we can start identifying what we want to tackle as first priorities.
In addition to getting the plugin up to date with the latest version of WordPress, I think some priorities include adding support for gutenberg, doing some code clean up and start looking at issues in this repo that still need addressing. We will also want to identify and reach out to anyone who is actively working on their own forks or the ecosystem of integration plugins for things like WooCommerce, etc.
For sure Gutemberg is an issue.. but i think it's secondary to gather the attention of the qTranslate* community around our new project.
My personal roadmap will be:
-start the new plugin
-do some public relations to gain attentions
-fix qtranslate for current wordpress and php7
-work on gutemberg integration (and if needed consider refactoring the whole code)
I'd vote for fixing the code for current WP and php7 before we try to do any announcements outside this repo to avoid confusion.
well, seems legit ;-) let's move my point 2 to point 3 ;-)
I agree with getting the fork going (for absolutely selfish reasons) but I have nothing to offer by way of coding as I am absolutely clueless. HOWEVER, I can offer my excellent moral support and I can also finish the Greek translation if that would help at all...
every help is appreciated, when it'll come the time we hope you'll spread the word ;-)
of course! :D
Hey, let's fork it and get going. The name doesn't matter! I don't have the experience to be good at being in charge, but I really hope to be able to contribute some once there is a fork and issues are defined that need to be worked on.
PS I agree with everything @colinloretz has said/done. Thank you!!!
I won't have much time for it but i will try to help with some coding. Two things:
Current status with issues/PR
The current issues and PRs have not been imported yet. I think it would be good to import everything we can, including the closed tickets because they contain some information about the past issues. History can sometimes help to fix new bugs.
I'm not completely sure how it works for a forked project. Usually the goal is to have back and forth exchanges between the parent and child projects, even by sharing some tickets. But in our case the parent repo looks definitely dead. So we might need to detach the relation completely.
Dev and releases workflow
We need to organize a workflow so that:
- we can develop fixes and new features
- we can push some releases to a WP plugin.
The main question is how to validate the releases. There is apparently no test workflow at all so this will be the most critical part to avoid regressions. We should keep a master branch very clean and only merge stuff that we are at least confident about.
Personally i use very little fonctions from the client side (JS), only standard WP components. I don't use any JSON configuration file for integration so i won't be much of help to test this. I'm more concerned by the server part with the content DB and the URL redirections to be sure it stores and converts what i expect.
So at this point i don't really know how we are going to handle properly the regression tests and releases. Any ideas?
@herrvigg I have used the JSON configuration file, but it doesn't strike me as a very well-implemented feature. In principle a plugin probably shouldn't interface with users (who are potentially not programmers) at this level of complexity, right? I don't totally understand the reason why it has to be setup this way. And (as noted in the documentation here) it is a pain to debug. Does anyone agree with this? Can anyone envision a better situation?
Also the whole thing where users are instructed to inspect custom fields and input their ids in a text field just doesn't strike me as very elegant (and I've tried it and never gotten it to actually work).
Also – totally unrelated – has anyone heard anything from @funkjedi of acf-qtranslate? Seems like someone who has recently dealt with qTranslate-X in a major way.
The fork is up at https://github.com/qTranslate/qtranslate-x. We can rename the repo and sever the forked connection to the parent once we're ready to do that. No new code has been added yet.
I have set it up so that you can't push to master and you can't merge into master without 2 pull request reviews. @herrvigg Let's create an issue for tests/validation of releases in the new repo so we can have that conversation there.
I've just come across this discussion, I'd like to say THANK YOU for you work, since I use this plugin on many websites and I'm getting worried about its future compatibility. I'll be glad to help testing and donating.
I have only used this plugin in one site but I am really fond of it and I would hate it to see it disappear. I wish I could help myself, but my coding skills are limited. Thank you for your work on keeping it available.
@colinloretz @herrvigg Seeing as you two are taking the lead here, there are a couple of repos under the qTranslate-Team for various plugins to integrate with other plugins (i.e. the js-composer one for integrating with WPBakery Visual Composer, and the WooCommerce integration plugin). Do you plan to fork them under your new organization as well? It would make sense, rather than having them splinter into unrelated orgs.
I'm more of a OS level developer (BASH, Perl, Ruby (not Rails), Python, and many others that have been lost to the annals of time... FORTRAN anyone?), but I do dabble in PHP and Java when needed. I would be willing to chip in to help out, and if the other repos get ported, I'd be willing to take on the js-composer and if no-one else wants to jump on WooCommerce, I'd be willing to help there too (as well as the core plugin).
As for name:
- qTransferendum (Translate in Latin)
- qTranslate-NG (as in Next Generation).
- qTranslate-WP
Just to keep you updated, i am currently migrating all the issues in a new repo:
- I wanted to keep all the issues/PR history of the project as an independent backlog and the only way is to duplicate them. The previous contributors might receive many notifications. Sorry for the spam but it's for the good cause ;)
- The old repo (this one) is completely abandoned. So i preferred to create a new repo from a mirror (bare) rather than a basic fork. A fork is only interesting if there are some exchanges between the projects but it comes with limitations and there is actually no way to undo the link in github later! You must create a new repo but then you'd lose all the issues.
The migration of the issues backlog is quite a long process:
- I am duplicating everything: open and closed issues including the PRs (which are a special case of issue) and all the comments. The backlog contains 592 issues and 2159 comments.
- I improved an existing migration tool for my needs. An abuse prevention algorithm prevents me to duplicate all quickly (e.g. because of the notifications). I have to add delays for every item and way even longer (~30mn) before bigger chunks.
- The new issues have to be recopied for an authorized user in the new repo (hence myself at the moment). The original content is embedded in the issue with links to the original issue and mentions to the contributors.
- The PR are created as standard issues, i didn't manage to use the head of the requested branch to re-create a true PR. I didn't mange to use the cross-repo references through the user and/or the project. Anyway it's better than nothing because we still can check the original PR from those.
- The new issues and PR have special labels so they can be handled separately later on.
My new repo is locked for all at the moment but my goal is transfer it later to the new organization when it's ready. So i don't link it here yet to avoid confusions.
We'll keep you updated when the new repo is ready to use.
Hello to everybody,
also my agency use this plugin for a great number of projects and of course is better than all other language plugin.
So @herrvigg please keep us update when you have a repo to share! 👍
hello,
the migration is done with all the tickets and i also migrated the releases!
Now i'm trying to understand the status of the different branches. It's quite a mess. The master branch has been left aside but it has some commits i don't find in the stable branch which contains the last release.
The pre-release 3.4.6.9 was never released in WP and i have no clue about its current state. I think i will rather go back in github and start over from 3.4.6.8 which is the last official release in WP.
Then it will take some work to revive what has been done since then but it will not be my priority.
Also, we need to find a new project name before the project becomes available for all.
For search purposes I think it could be good to include the word language in the name.
Something like qTranslate-lang.
Hooray, the new repo is now ready for a new life!
I propose to name the new project qTranslate-XT for eXTended, even recalling the previous name (i didn't plan to, but it sounds quite good to me). The new project is now moved under the new organization: https://github.com/qTranslate/qtranslate-xt
The last official release is 3.4.6.8 which corresponds to the last WP version. There has actually been quite some work done since then under the stable branch.
The last official pre-release was 3.4.6.9 but there were two other pre-releases prepared internally, though never tagged: 3.4.7 and 3.4.8. So i added these tags and i consider the last commit by John Clause to go in 3.4.8, even though the last commits go slightly beyond the initial list of features. It's mostly about notice and integration of plugins. I can't really say much about them but it seems stable to me so let's take all we can.
Then i re-organized the branches. The previous master was very much obsolete so i renamed it old-master just to keep it. We should now work on the master branch and then move the new stuff to the releases under the stable branch when it's ready.
The first tasks are now to prepare the first official release. One of the first thing would be to rename the internal references to qTranslate-XT if you agree with this. Then my priority would be the most urgent fixes to make it run with a recent PHP7. On my side i made some custom fixes but in the old PR i found this one which looks pretty good to me.: #581
Keep in touch!
I like the name qTranslate-XT!
The master branch is now active in the new repo.
I've started with the most urgent fixes such as those annoying warning in PHP 7.1. The new plugin has also be renamed in the header info with qTranslate-XT so it's clearer in the plugins list.
You should always desactivate the previous / activate the new plugin after pulling a new version of the repo. If you ever have both qTranslate-X and qTranslate-XT in the plugins folder, you should keep only 1 plugin active at a time. Also be aware that the options are not renamed (and i don't plan to), so qTranslate-XT simply uses the existing ones from qTranslate-X. All seems to works well so far.
I've submitted the new plugin for review to wordpress.org so hopefully we can have some official releases soon. It can take up to 10 days for the review. I also figured out that a few files (dev files, .po, experimental stuff) should be removed from the repo before an official release to wordpress but that's quite a minor thing.
Well the rejection was quite fast...
It won't work with qTranslate-XT or any qTranslate-whatever. We need to find a new name and rebrand it completely, even though they "KNOW qTranslate abandoned the project". And even qTranslate-X... How annoying. But we'll have to be creative and try differently.
From Wordpress plugins:
Your plugin has been rejected because you do not appear to work for or legally represent qTranslate
We're no longer accepting plugins that begin with (or are in total) a trademarked product name or term as the name or slug of a plugin (ex: facebook or google-maps-bathrooms). Nor are we accepting plugins that include the name of another plugin at the beginning of the name/slug (eg: contact-form-7-music).
We also do not accept "permission" from companies for you to use this, because we do not wish to be involved in potential issues later on when they may revoke permission. Simply put, don't use someone ELSE'S name for YOUR plugin.
The slug for your plugin is generated based on the name you enter on the app plugin page, with hypens inserted in place of spaces. This means if you were to name your plugin "My Really Cool Cookie Jam" then your URL on WordPress.org would be http://wordpress.org/plugins/my-really-cool-cookie-jam
This becomes a larger issue when plugins use the names of other plugins in their own.
For example, if you have written an add-on plugin for WooCommerce, you may not name it "WooCommerce Improved Product Search" as that would generate the slug "woocommerce-improved-product-search" and that would conflict with the trademark of 'WooCommerce.' That said, it would be acceptable to submit the name "Woo Improved Product Search" which would use the slug "woo-improved-product-search" (woo not being trademarked you see).
As another example, if you have a plugin that integrates a service with a Easy Digital Downloads, you may call it "My Service Integration for Easy Digital Downloads", but you may not use "Easy Digital Downloads - My Service Integration". Alternately you could use 'EDD My Service Integration' and that too would be permitted.
None of this impacts your display name of your plugin. The display name is generated from your readme.txt, and that can be whatever you'd like. Keep in mind, you should use "My Product for Other Product" as the description. Consider the example of Keurig. If you made an eco-friendly brew cup, you could market it "EcoBrew Pod for Keurig" but you could NOT attempt to market it as "Keurig EcoBrew Pod." The latter implies a direct relationship to Keurig and may be against the law in some countries.
You are more than welcome, and encouraged, to include it in the description of the plugin in the ReadMe.txt file, but it cannot be in the name/slug of the plugin as described above.
Please resubmit this plugin with a better name and we will review it. If you're confused and want to check a name before resubmitting, just reply to this and ask :)
http://wordpress.org/plugins/add/
Note: WE KNOW qTranslate abandoned the project.
You STILL have to totally rebrand everything, CREDIT everyone, and be a fair fork.
Firstofall.. shouldn't this conversation continue on the new fork/repo?
Second.. let's try to start to be creative (but without leaving too much the nest).. how about something like "KUKU translate" ? in italian "q" sound like "ku" and doubling it we can have some sort of joke.. (also there's nothing in plugins' repo by the name KUKU)
Also xTranslate may do the trick to go over the wordpress limitation.. but i think there's something for google chrome by that name.
So i wrote to the plugin admin of wordpress about the 3 last points (rebrand, credit, fair fork) also asking if something like qNewTranslate (a dumb example not starting with qTranslate) would be accepted and here is the answer:
Yes, New qTranslate would be accepted BUT like you said, it's kinda stupid. Take a day to come up with something all new :) People have used yTranslate and xTranslate, and it just confuses users.
Credit means in the code, in the readme, and so on.
A fair fork means you have to actually provide some changes of substance. Fixing things is one thing, but again, there are already forks so if it's not going to be actually DIFFERENT, we're unlikely to accept this.
So yes i understand, to become a new plugin it has to be different enough from the original one, also for branding issues. The problem is that no one is representing the official qTranslate anymore, neither John Clause or Qian Qin are active. Therefore both the qTranslate and qTranslate-X projects should be considered to be dead, we cannot claim this ownership on our own. To do it right we should look beyond that, maintain at least a legacy compatibility with the DB but move on with new features. This could become a further goal but i won't spend too much time on it now.
At this time I consider qTranslate-XT is only a "bridge project" so we can start deal with the very urgent maintenance. I think it's reasonable to keep this name as long as we only remain on github. The project also needs a lot of refactoring, it's quite a big mess (some also due to the wordpress framework). In the future we might rename everything to rebrand it as a new plugin once we have changes relevant enough to justify it.
So yes i agree we should move to the new repo! Everyone willing to collaborate is welcome to participate, sending tickets and PRs. As said i also migrated all the backlog so there's quite a lot to sort out already there. If you are a good developer we can also move you into the organization.
So let's do it and move on :)
https://github.com/qtranslate/qtranslate-xt
Hi guys. New to the party, but absolutely thrilled that someone is taking charge of qT.
Can I ask if anyone has thought of just taking over the existing plugin in the WP repository? There's a whole procedure for it here: https://developer.wordpress.org/plugins/wordpress-org/take-over-an-existing-plugin/
I did it recently for a plugin that I considered essential to my workflow (https://wordpress.org/plugins/jf3-maintenance-mode/), but hadn't been updated for about 4 years.
It wasn't too onerous a task - you just need to attempt to contact the original author. His email and website weren't active, so I left a post in the plugin's support forum. Waited a month for a response, and then emailed plugins@wordpress.org - only took about a month or so after that.
Cheers
Peter
Good suggestion!
I had a few discussion with the responsible of the plugins at wordpress. I asked to upload it as a new plugin so it was not about taking over but maybe this could be a solution in this case so i can give it a try. The author has disappeared for 2 years and even this administrator at wordpress found it was a real shame! The main question is the qTranslate trademark. Who owns it? It's quite a tricky question, as even qTranslate-X is a fork of qTranslate. But what happens if everyone disappears? Good question.
Clearly my goal would not be to own it myself but give it back to the community through a new organization or a real TEAM (unlike the fake qTranslate-Team). This plugin is still quite popular, even after being dead for 2 years, so it should be worth it.
My understanding of taking over an abandoned plugin is that the original contributors remain as contributors (they're not removed at any rate), so no change in ownership of the trademark has occurred - all that's happening is that other people are allowed to maintain the code. All plugins in the repository are licensed under open source licences anyway, so you have an absolute right to modify the code. Providing you're not actively claiming the trademark as your own, I don't think there'd be too much problem (although I'm no lawyer :-) )
i need a help with a site i have all multilingual, only spanish and english with the plugin q translate x, but i have a fear that when upgrading the latest theme and wordpress version of wordpress everything will messed up....
i don't know what happened with the support of this plugin, but i found this forum here in github, so i expect someone can give me a light in this, since the site is live and i need to have it without any problem.
i also have read a post about migrating to wpml and then to polylang, but in need a detailed explanation of all the possible cases or situations to take into account before doing something.
please let me know !!!!
qTranslate-X is not maintained anymore, it's dead for more than 2 years. We have moved from the existing code to a new project called qTranslate-XT. It's fully compatible with qTranslate-X, there are already some fixes and new features but it's only available on github at the moment: https://github.com/qTranslate/qtranslate-xt
Check out the README and FAQ i wrote, it should answer all of your main questions. For other questions feel free to post a ticket on: https://github.com/qTranslate/qtranslate-xt/issues
Hi aledelord90 (et al) - I've just completed a big project updating the codebase for a huge site that uses qT-X. In the process I have updated to the latest version of qT-XT, and you'll be pleased to hear that I have encountered no problems at all (other than existing, long-standing bugs, of course!).
Awesome! Great to hear :)