Merge branch 'master' into config-support

docs/deploying/cgi.rst

@@ -6,7 +6,7 @@ is supported by all major servers but usually has a less-than-optimal
 performance.
 
 This is also the way you can use a Flask application on Google's
-`AppEngine`_, there however the execution does happen in a CGI-like
+`App Engine`_, there however the execution does happen in a CGI-like
 environment.  The application's performance is unaffected because of that.
 
 .. admonition:: Watch Out
@@ -15,9 +15,9 @@ environment.  The application's performance is unaffected because of that.
    have in your application file, is inside an ``if __name__ ==
    '__main__':`` or moved to a separate file.  Just make sure it's not
    called because this will always start a local WSGI server which we do
-   not want if we deploy that application to CGI / appengine.
+   not want if we deploy that application to CGI / app engine.
 
-.. _AppEngine: http://code.google.com/appengine/
+.. _App Engine: http://code.google.com/appengine/
 
 Creating a `.cgi` file
 ----------------------

docs/patterns/caching.rst

@@ -34,7 +34,7 @@ memcached server then::
     from werkzeug.contrib.cache import MemcachedCache
     cache = MemcachedCache(['127.0.0.1:11211'])
 
-If you are using appengine, you can connect to the appengine memcache
+If you are using App Engine, you can connect to the App Engine memcache
 server easily::
 
     from werkzeug.contrib.cache import GAEMemcachedCache

docs/patterns/lazyloading.rst

@@ -8,7 +8,7 @@ that uses decorators has to be imported upfront or Flask will never
 actually find your function.
 
 This can be a problem if your application has to import quick.  It might
-have to do that on systems like Google's AppEngine or other systems.  So
+have to do that on systems like Google's App Engine or other systems.  So
 if you suddenly notice that your application outgrows this approach you
 can fall back to a centralized URL mapping.