refactored plugin I18N2

added actions script

1 files changed, 42 insertions, 49 deletions

diff --git a/README.md b/README.md
index 9b2eac8..07bcb27 100644
--- a/README.md
+++ b/README.md
@@ -1,81 +1,74 @@
 JWebmail
 ========
 
-This is a rewrite of oMail by Oliver Müller <om@omnis.ch>.
+This is based on concepts of oMail by Oliver Müller <om@omnis.ch>.
 
-oMail has not seen much progress in the last two decades
-so my <jannis@fehcom.de> goal is to bring it up to date.
-OMail was tied to qmail. JWebmail is not so tightly bound.
+JWebmail is a webmail server build on top of Mojolicious.
 
 This includes:
-- Using a perl web framework and leave the deprecated CGI behind.
-  You can still use it in a cgi setup if you like but you now
-  have the option of plack/psgi and fcgi as well as the
-  build in server hypnotoad.
+- Using a Perl web framework and leave the deprecated CGI behind. You can
+  still use it in a CGI setup if you like but you now have the option of
+  plack/psgi and fcgi as well as the build in server hypnotoad.
 - Set up a MVC architecture instead of a single file.
-- Improve security by only running a small part of the
-  model with elevated privileges.
-- Make sure it works well with sqmail and its authuser
-  authenticator and maildir but also permit other setups
-  (currently not supported but adding more should be easy).
-  Maybe I even add a POP or IMAP based backends instead
+- Improve security by only running a small part of the model with elevated
+  privileges.
+- Make sure it works well with sqmail and its authuser authenticator and
+  maildir but also permit other setups (currently not supported but adding
+  more should be easy). Maybe I even add a POP or IMAP based back-ends instead
   of reading them from disk.
 
 
 ## License
-JWebmail is available under the GNU General Public License
-version 3 or later.
+JWebmail is available under the GNU General Public License version 3.
 
 ## JWebmail-webmail - INSTALL
-You still need to install sqmail and setup
-an external web server.
-
-## Future feature list
-- [ ] address book support
-
-### Read
-- [ ] bounce
-- [ ] add links on email addresses in header : click = add into addressbook
+You need a moderately new version of Perl (v5.22+)
+You need access to CPAN.
+You need to install sqmail.
+It is recommended to use an external web server like Apache or Nginx.
 
 
 Posts
 -----
 
-* Complain about IPC::Open2 ignoring 'open' pragma
-* Complain about undef references causing errors, and non-fine granular switch no strict 'refs'
-* Thank for perldoc.org
+- Complain about IPC::Open2 ignoring 'open' pragma
+- Complain about undef references causing errors, and non-fine granular
+  switch no strict 'refs'
+- Thank for perldoc.org
 
 
 I18N patch url_for
 ------------------
 
-I have taken the monkey patching approach that was taken by Mojolicious::Plugin::I18N.
-I used `can` to get the old method for looser coupling and used the Mojo::Util::monkey_patch
-instead of manually doing it. This is probably overkill.
-
-I'm desperately looking for a different approach. Yeah the monkey patching works great,
-but it violates the open-closed principal. But I cannot find an appropriate alternative.
-Extending the controller and overriding url_for does not work cleanly as the user directly
-inherits from Mojolicious::Controller.
-Also going the 'better' approach of solving at the root by using an extension of
-Mojolicious::Routes::Match->path_for and supplying it to the controller by setting
-match does not work as it is on the one hand extremely difficult to inject it in
-the first place and the attribute is overwritten in the dispatching process anyways.
-One issue when taking the Match approach is that it needs knowledge of the stash
-values which can cause cyclic references.
+I have taken the monkey patching approach that was taken by
+Mojolicious::Plugin::I18N. I used `can` to get the old method for looser
+coupling and used the Mojo::Util::monkey_patch instead of manually doing it.
+This is probably overkill.
+
+I'm desperately looking for a different approach. Yeah the monkey patching
+works great, but it violates the open-closed principal. But I cannot find
+an appropriate alternative. Extending the controller and overriding url_for
+does not work cleanly as the user directly inherits from Mojolicious::Controller.
+Also going the 'better' approach of solving at the root by using an extension
+of Mojolicious::Routes::Match->path_for and supplying it to the controller
+by setting match does not work as it is on the one hand extremely difficult
+to inject it in the first place and the attribute is overwritten in the
+dispatching process anyways. One issue when taking the Match approach is
+that it needs knowledge of the stash values which can cause cyclic references.
 
 I thought of three approaches injecting the modified Match instance into the class:
 
 1. Extending the Mojolicious::Controller and overriding the new method.
    This has the issue that inheritance is static but one can use Roles that
    are dynamically consumed.
-2. Overriding build_controller in Mojolicious. To make this cleanly it needs to be monkey patched
-   by the plugin which is exactly what we want to avoid. :(
-3. The matcher can be set in a hook relatively early in its lifetime
-   and hooks compose well.
-
-A completely different option is to use the router directly and register a global
-route that has the language as parameter. But omitting the language leads to problems.
+2. Overriding build_controller in Mojolicious. To make this cleanly it needs
+   to be monkey patched by the plugin which is exactly what we want to avoid. :(
+3. The matcher can be set in a hook relatively early in its lifetime and
+   hooks compose well.
+
+A completely different option is to use the router directly and register a
+global route that has the language as parameter. But omitting the language
+leads to problems.
 
 One can use a redirect on root. Very easy but also not very effective.