[glotpress-updates] [GlotPress] #462: Make GlotPress a plugin?

[GlotPress]

#462: Make GlotPress a plugin?
--------------------------+-----------------------------
  Reporter:  joostdevalk  |      Owner:
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  Awaiting Review
 Component:  General      |    Version:
Resolution:               |   Keywords:
--------------------------+-----------------------------

Comment (by GregRoss):

 Replying to [comment:7 markoheijnen]:
 > I strongly am against having it as a plugin. This due the fact that
 BackPress is an issue but not one GlotPress needs to care much about. In
 general it's underlying code.

 I think any app needs a good base to start from, GlotPress needs to be
 concerned about the foundation it's built on.  Clearly BackPress has
 issues that need to be addressed within the context of GlotPress so the
 project needs to spend some time taking care of them.

 Replying to [comment:7 markoheijnen]:
 >Moving it to a plugin doesn't fix much since most issues are related to
 GlotPress as a project. Only a hand full would be fixed but it's problems
 like the easy but stupid integration to WordPress login system.

 Moving to a plugin does several things, including freeing up time that
 would otherwise have to be spent dealing with things WordPress already
 does.  That doesn't mean WordPress is a perfect fit or won't need effort,
 just that it may be a better choice than the alternatives.

 Replying to [comment:7 markoheijnen]:
 > The reason I would like GlotPress to be a single app is the fact that it
 is that. Fixing things like easier installation, user management,
 authentication etc. are easy to do then too. Maybe easier then building a
 plugin because GlotPress has full control.

 With obviously limited resources to contribute to GlotPress, is rebuilding
 installation, user management, authentication, etc. really the best use of
 the development time we have?  Not only do you have to rebuild all of that
 code, you have to end up supporting it forever (including security
 issues).

 >There is no need for now to care about backwards compatibility.

 You always have to pay attention to backwards compatibility ;)

 >Also as a plugin a lot of things don't make sense like most of the admin
 panel.

 As a plugin, we can turn off anything we don't need in WordPress, don't
 need posts?  No problem, just remove them from the menu.  However, I
 expect more likely many users (like myself) use GlotPress as part of
 another project, which already has a WordPress install, in which case
 GlotPress just becomes another plugin in a pre-existing WordPress setup.

 > It's not like bbPress or BuddyPress due to the fact that does things can
 live next to your normal site. GlotPress will not.

 I'm not sure I follow you here, WordPress and GlotPress could easily live
 together in the same site, in fact I have that exact setup already running
 using iframes.

 Replying to [comment:7 markoheijnen]:
 > Feedback to GregRoss list and a bit more
 > - I wouldn't say that WordPress is mature for a framework if you look at
 database handling

 I think that the majority of it is and while all frameworks have different
 strengths and weaknesses, it's maintained and isn't going anywhere.

 Replying to [comment:7 markoheijnen]:
 > - Automattic updates are fun but not a pro/con for GlotPress

 Automatic updates are certainly a pro for any application, but especially
 something like GlotPress that deals with user accounts and security.  I
 could argue that if GlotPress did it's own authentication and user
 management it would be even more important that if it was just a plugin.

 Replying to [comment:7 markoheijnen]:
 > - One click install doesn't matter much and also incorrect for WordPress
 plugin.

 Simplified installation is a big bonus for applications, perhaps a better
 name would be simplified installation process.  WordPress has spent lots
 of time getting to their "5 minute install" and as WordPress is supported
 on so many hosting providers it would make GlotPress even easier to
 install.  Piggy backing on this already proven and widely available
 process makes GlotPress easier to install and support.

 Replying to [comment:7 markoheijnen]:
 > - GlotPress has i18n except it doesn't use it by default. Empty
 textdomain is fine.

 That's fine, it just, as you said before, has never generated a pot file
 or even created a translation folder.

 Replying to [comment:7 markoheijnen]:
 > - Future proof would be a 0 for having it as a WordPress plugin.

 I would suggest WordPress is as future proof as we can get, in the sense
 that the project isn't going to fold up any time soon like BackPress did.
 For me future proof doesn't mean that things won't change, but that
 support for the framework isn't going to disappear due to lack of
 contributors.

 Replying to [comment:7 markoheijnen]:
 > - Current GlotPress can be installed but not under all systems. Having
 it forked or other framework would be a 1 for me.

 I'm not quite sure what you mean here, GlotPress currently can only be
 installed on an Apache server as a standalone app.  Supporting multiple
 forks and frameworks seems like a massive effort without anyone to support
 such an effort.  It would be like having a fork of WordPress to support
 Apache install, one to support IIS installs and one to support Nginx.

 Replying to [comment:7 markoheijnen]:
 > - User management can be build in and be build for GlotPress. WordPress
 would be a 0 for me due to so many different roles etc.

 Again, with limited resources to work on this, why rebuild what already
 exists?  Sure WP's roles/user system may not be perfect but that's
 something we can investigate and at worst extend to what we need without
 having to rewrite everything from the ground up.

 Replying to [comment:7 markoheijnen]:
 > - The SEO thing can easily be fixed in GlotPress but isn't really that
 important for GlotPress in comparison to your site in WordPress.

 For some people this may be very important, obviously for joostdevalk it's
 important enough to have written a plugin for GlotPress to accomplish it.
 If GlotPress is going to be more than just "the software WordPress uses to
 do translations", more of this kind of features will be required.  They
 may not seem important to everyone, but they are to some and will drive
 the adoption of GlotPress.

 Replying to [comment:7 markoheijnen]:
 > Last but not least, GlotPress currently is also really accessible to
 contribute back. It's better then WordPress since even if the patch is out
 of scope, I will still look at it.

 I would disagree with this in some respects.  GlotPress is harder to
 contribute to as the code base is different enough and has little
 documentation.  When I was doing a few of my plugins, trying to track down
 how to modify the header/footer/etc. was a real challenge and I spent a
 good bit of time search through the code.  In comparison, in WordPress,
 making these kinds of changes are well documented with lots of examples.

 Having said that, the flip side is that we lose control over those pieces
 of GlotPress that the WordPress code base would take over.  WordPress is
 pretty easy to extend, I would not think there would be much in the way of
 patches we would be sending back to WP Core to support GlotPress.  Could
 that turn out to be a showstopper at some point?  Maybe, but that is true
 with any framework that isn't your own.

 It really comes down to how much time and effort the project wants to
 spend supporting a framework in comparison to working on GlotPress
 features.

 Forking BackPress (or rolling our own framework) is going to take a major
 amount of time and effort to do and support in the long run.

 Don't reinvent the wheel when there are lots of wheels out there we can
 use, whether it is WordPress or another framework.

--
Ticket URL: <https://glotpress.trac.wordpress.org/ticket/462#comment:10>
GlotPress <https://glotpress.trac.wordpress.org>
Easy comin', easy goin'