Docs: Spanish translation.

docs/locale/es/LC_MESSAGES/blog-importing.po

@@ -0,0 +1,228 @@
+# 
+msgid ""
+msgstr ""
+"Project-Id-Version: Mezzanine 3.1.9\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2014-08-19 13:59-0600\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <[email protected]>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: ../blog-importing.rst:3
+msgid "Importing External Blogs"
+msgstr ""
+
+#: ../blog-importing.rst:5
+msgid ""
+"Mezzanine has the ability to import blog posts from other blogging platforms"
+" using a `Django management command "
+"<http://docs.djangoproject.com/en/dev/howto/custom-management-commands/>`_. "
+"These are the currently supported formats and their commands:"
+msgstr ""
+
+#: ../blog-importing.rst:10
+msgid "`WordPress <http://wordpress.org>`_: ``import_wordpress``"
+msgstr ""
+
+#: ../blog-importing.rst:11
+msgid "`Blogger <http://blogger.com>`_: ``import_blogger``"
+msgstr ""
+
+#: ../blog-importing.rst:12
+msgid "`Tumblr <http://tumblr.com>`_: ``import_tumblr``"
+msgstr ""
+
+#: ../blog-importing.rst:13
+msgid "`Posterous <http://posterous.com>`_: ``import_posterous``"
+msgstr ""
+
+#: ../blog-importing.rst:14
+msgid "`RSS <http://en.wikipedia.org/wiki/RSS>`_: ``import_rss``"
+msgstr ""
+
+#: ../blog-importing.rst:16
+msgid ""
+"Each command takes a Mezzanine username to assign the blog posts to as well "
+"as certain arguments specific to the blog platform. For example to import an"
+" existing Wordpress blog::"
+msgstr ""
+
+#: ../blog-importing.rst:22
+msgid ""
+"Use the ``--help`` argument to learn more about the arguments specific to "
+"each blog platform's command. For example you can see all options for "
+"Wordpress by running::"
+msgstr ""
+
+#: ../blog-importing.rst:29
+msgid "Considerations"
+msgstr ""
+
+#: ../blog-importing.rst:31
+msgid ""
+"There are some known issues with HTML formatting loss - specifically where a"
+" heading tag is followed by a paragraph tag or another block HTML element "
+"that is not typically enclosed with a ``<p>`` tag is followed by a "
+"paragraph. This depends heavily on the originating platform and how it "
+"encodes the blog post's copy. The import processor gets this about 90% "
+"correct but you may need to do some quick clean up afterwards."
+msgstr ""
+
+#: ../blog-importing.rst:39
+msgid ""
+"Generally speaking you shouldn't be able to import your data twice. There is"
+" a check in place to either create or update for both comments and posts as "
+"they are processed, so even if you run the importer multiple times you "
+"should only end up with data imported once. However if you have changed any "
+"data this will be overwritten."
+msgstr ""
+
+#: ../blog-importing.rst:46
+msgid "Importing from Wordpress"
+msgstr ""
+
+#: ../blog-importing.rst:49 ../blog-importing.rst:77 ../blog-importing.rst:105
+#: ../blog-importing.rst:118
+msgid "Dependencies"
+msgstr ""
+
+#: ../blog-importing.rst:51 ../blog-importing.rst:107
+msgid "Mark Pilgrim's `feedparser <http://code.google.com/p/feedparser/>`_"
+msgstr ""
+
+#: ../blog-importing.rst:53
+msgid ""
+"The first step is to export your Wordpress data. Login to Wordpress and go "
+"to ``Settings -> Export``. Here you can select your filters, otherwise only "
+"published posts will be exported. Once you have saved your export file make "
+"a note of the location you saved it to."
+msgstr ""
+
+#: ../blog-importing.rst:60
+msgid ""
+"It is faster to import directly from your filesystem if you can, especially "
+"if you have a large blog with lots of comments."
+msgstr ""
+
+#: ../blog-importing.rst:63
+msgid ""
+"The next step is to run the ``import_wordpress`` command where the ``url`` "
+"argument contains the path or URL to your export file::"
+msgstr ""
+
+#: ../blog-importing.rst:69
+msgid "Importing from Blogger"
+msgstr ""
+
+#: ../blog-importing.rst:71
+msgid ""
+"The Blogger import currently has one known limitation which is a maximum of "
+"500 blogs or 500 comments per blog that can be imported. If you have more "
+"than this the import will still work but end up being truncated."
+msgstr ""
+
+#: ../blog-importing.rst:79
+msgid ""
+"Google's `gdata <http://code.google.com/p/gdata-python-client/>`_ Library"
+msgstr ""
+
+#: ../blog-importing.rst:81
+msgid ""
+"The first step is to obtain your Blogger ID. Login to Blogger and go to "
+"``Settings``. You'll see that the address in your browser end with "
+"``BlogID=XXX`` where ``XXX`` is your Blogger ID. Make a note of this and "
+"while you're in settings, go to ``Site Feed`` then set ``Allow Blog Feeds`` "
+"to be ``Full`` - this will give you all your data when you run the import."
+msgstr ""
+
+#: ../blog-importing.rst:88
+msgid ""
+"The next step is to run the ``import_blogger`` command where the ``blogger-"
+"id`` argument contains the Blogger ID you retrieved::"
+msgstr ""
+
+#: ../blog-importing.rst:94
+msgid "Importing from Tumblr"
+msgstr ""
+
+#: ../blog-importing.rst:96
+msgid ""
+"Simply run the ``import_tumblr`` command where the ``tumblr-user`` argument "
+"contains your Tumblr username::"
+msgstr ""
+
+#: ../blog-importing.rst:102
+msgid "Importing RSS"
+msgstr ""
+
+#: ../blog-importing.rst:109
+msgid ""
+"Simply run the ``import_rss`` command where the ``rss-url`` argument "
+"contains the URL for your RSS feed::"
+msgstr ""
+
+#: ../blog-importing.rst:115
+msgid "Importing from Posterous"
+msgstr ""
+
+#: ../blog-importing.rst:120
+msgid ""
+"Kenneth Reitz's `requests <http://docs.python-"
+"requests.org/en/latest/index.html>`_"
+msgstr ""
+
+#: ../blog-importing.rst:122
+msgid ""
+"Simply run ``import_posterous`` command with the right params. You need to "
+"get your API key from the `Posterous API Reference "
+"<https://posterous.com/api>`_::"
+msgstr ""
+
+#: ../blog-importing.rst:128
+msgid ""
+"If you have more than one blog on your posterous account check out the "
+"``-posterous-host`` option. Be aware that like the tumblr importer, this "
+"leaves your media assets on the Posterous servers. If you're worried about "
+"posterous being shut down you may want want to have a closer look at the API"
+" to actually export your media."
+msgstr ""
+
+#: ../blog-importing.rst:135
+msgid "Importer API - Adding New Importers"
+msgstr ""
+
+#: ../blog-importing.rst:137
+msgid ""
+"The importer system has been designed to be extensible so that import "
+"commands can easily be added for other blogging platforms."
+msgstr ""
+
+#: ../blog-importing.rst:140
+msgid ""
+"Each importer's management command is located in the "
+"``mezzanine.blog.management.commands`` package, and should have its module "
+"named ``import_type`` where ``type`` represents the type of import the "
+"command is for. This module will then contain a class named ``Command`` "
+"which subclasses ``mezzanine.blog.base.BaseImporterCommand``."
+msgstr ""
+
+#: ../blog-importing.rst:147
+msgid ""
+"The first step is to define any custom arguments the command will require "
+"using Python's `optparse <http://docs.python.org/library/optparse.html>`_ "
+"handling."
+msgstr ""
+
+#: ../blog-importing.rst:151
+msgid ""
+"The main responsbility of the ``Command`` class is then to implement a "
+"``handle_import`` method which handles retrieving blog posts and comments "
+"from the particular blogging platform. The ``handle_import`` method is "
+"passed a dictionary of options for the command. The ``add_post`` and "
+"``add_comment`` methods should be called inside the ``handle_import`` "
+"method, adding posts and comments respectively. The ``add_post`` method "
+"returns a post to be used with the ``add_comment`` method. For example::"
+msgstr ""

docs/locale/es/LC_MESSAGES/caching-strategy.po

@@ -0,0 +1,156 @@
+# 
+msgid ""
+msgstr ""
+"Project-Id-Version: Mezzanine 3.1.9\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2014-08-19 13:59-0600\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <[email protected]>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: ../caching-strategy.rst:3
+msgid "Caching Strategy"
+msgstr ""
+
+#: ../caching-strategy.rst:5
+msgid ""
+"Mezzanine takes great care to appropriately minimize database queries. This "
+"strategy enables Mezzanine to perform well without a caching configuration. "
+"However, caching is also well-supported in the event that you wish to "
+"implement customized caching for your Mezzanine site. Mezzanine is "
+"preconfigured to cache aggressively when deployed to a production site with "
+"a cache backend installed."
+msgstr ""
+
+#: ../caching-strategy.rst:14
+msgid ""
+"By using Mezzanine's bundled deployment tools, Mezzanine's caching will be "
+"properly configured and in use for your production site. Consult the "
+":doc:`deployment` section for more information. If you would like to have a "
+"cache backend configured but to use a different caching strategy, simply "
+"remove the cache middleware described in the next section."
+msgstr ""
+
+#: ../caching-strategy.rst:22
+msgid "Cache Middleware"
+msgstr ""
+
+#: ../caching-strategy.rst:24
+msgid ""
+"Mezzanine's caching system employs a hybrid approach which draws from "
+"several popular caching techniques and combines them into one overall "
+"implementation. Mezzanine provides its own implementation of `Django's page-"
+"level cache middleware <https://docs.djangoproject.com/en/dev/topics/cache"
+"/#the-per-site- cache>`_, and behaves in a similar way."
+msgstr ""
+
+#: ../caching-strategy.rst:31
+msgid ""
+"Pages are fetched from cache by "
+"``mezzanine.core.middleware.FetchFromCacheMiddleware``, which should appear "
+"at the end of the ``MIDDLEWARE_CLASSES`` setting and therefore be activated "
+"at the end of the request phase. If a cache miss occurs, the request is "
+"marked as requiring a cache update, which is handled by "
+"``mezzanine.core.middleware.UpdateCacheMiddleware``, which in turn should "
+"appear at the start of ``MIDDLEWARE_CLASSES`` and therefore be activated at "
+"the end of the response phase."
+msgstr ""
+
+#: ../caching-strategy.rst:40
+msgid ""
+"Mezzanine's cache middleware differs from its Django counterpart in a few "
+"subtle yet significant ways:"
+msgstr ""
+
+#: ../caching-strategy.rst:43
+msgid ""
+"Setting ``CACHE_ANONYMOUS_ONLY`` to ``False`` will have no effect, so "
+"authenticated users will never use the cache system."
+msgstr ""
+
+#: ../caching-strategy.rst:45
+msgid ""
+"Cache keys include the ID for the current Django ``Site`` object, and device"
+" (see :doc:`device-handling`)."
+msgstr ""
+
+#: ../caching-strategy.rst:47
+msgid ""
+"Cache keys do not take Vary headers into account, so all unauthenticated "
+"visitors will receive the same page content per URL."
+msgstr ""
+
+#: ../caching-strategy.rst:52
+msgid "Two-Phased Rendering"
+msgstr ""
+
+#: ../caching-strategy.rst:54
+msgid ""
+"One approach to caching Django sites is to use `template fragment caching "
+"<https://docs.djangoproject.com/en/dev/topics/cache/#template- fragment-"
+"caching>`_, which defines the areas of templates to be cached. Another "
+"approach is two-phased rendering, which is the opposite. Using this method, "
+"all content is cached by default. We then define the sections of a template "
+"that should not be cached. These sections might be anything that makes use "
+"of the current request object, including session-specific data."
+msgstr ""
+
+#: ../caching-strategy.rst:63
+msgid ""
+"Accordingly, Mezzanine provides the start and end template tags "
+"``nevercache`` and ``endnevercache``. Content wrapped in these tags will not"
+" be cached. With two-phased rendering, the page is cached without any of the"
+" template code inside ``nevercache`` and ``endnevercache`` executed for the "
+"first phase. The second phase then occurs after the page is retrieved from "
+"cache (or not), and any template code inside ``nevercache`` and "
+"``endnevercache`` is then executed."
+msgstr ""
+
+#: ../caching-strategy.rst:72
+msgid ""
+"Mezzanine's two-phased rendering is based on Cody Soyland's `django-phased "
+"<https://github.com/codysoyland/django-phased>`_ and Adrian Holovaty's `blog"
+" post <http://www.holovaty.com/writing/django-two-phased-rendering/>`_ which"
+" originally described the technique."
+msgstr ""
+
+#: ../caching-strategy.rst:80
+msgid ""
+"The template code inside ``nevercache`` and ``endnevercache`` will only have"
+" access to template tags and variables provided by a normal request context,"
+" with the exception of any variables passed to the template from a view "
+"function. Variables added via context processors such as the current request"
+" and via Mezzanine's settings will be available. Template tag libraries "
+"should be loaded inside these areas of content so as to make use of their "
+"template tags."
+msgstr ""
+
+#: ../caching-strategy.rst:90
+msgid "Mint Cache"
+msgstr ""
+
+#: ../caching-strategy.rst:92
+msgid ""
+"The final step in Mezzanine's caching strategy involves a technique known as"
+" mint caching, in which the expiry value for any cache entry is stored in "
+"cache along with the cache entry itself. The real expiry value used is the "
+"given expiry plus the value defined by Mezzanine's "
+"``CACHE_SET_DELAY_SECONDS`` setting. Each time a cache entry is requested, "
+"the original expiry time is checked, and, if the expiry time has passed, the"
+" stale cache entry is placed back into the cache along with a new expiry "
+"time using the value of ``CACHE_SET_DELAY_SECONDS``. In this case, no cache "
+"entry is returned, which has the effect of essentially faking a cache miss, "
+"so that the caller can know to regenerate the cache entry. This approach "
+"ensures that cache misses never actually occur and that (almost) only one "
+"client will ever perform regeneration of a cache entry."
+msgstr ""
+
+#: ../caching-strategy.rst:106
+msgid ""
+"Mezzanine's mint cache is based on `this snippet "
+"<http://djangosnippets.org/snippets/793/>`_ created by `Disqus "
+"<http://disqus.com>`_."
+msgstr ""