Actualizado hasta 07/05

Author: gitnacho

_sources/book/doctrine.txt

@@ -963,13 +963,13 @@ Para más información sobre qué significan estos eventos y el ciclo de vida de
 
     Observa que el método ``setCreatedValue()`` no recibe argumentos. Este siempre es el caso para el ciclo de vida de las retrollamadas y es intencional: el ciclo de vida de las retrollamadas debe ser un método sencillo que se ocupe de transformar los datos internos de la entidad (por ejemplo, estableciendo un campo a creado/actualizado, generando un valor ficticio).
 
-    Si necesitas hacer alguna tarea más pesada ---como llevar el registro de eventos o enviar un correo electrónico--- debes registrar una clase externa como un escucha o suscriptor de eventos y darle acceso a todos los recursos que necesites. Para más información, consulta :doc:`/cookbook/doctrine/event_listeners_subscribers`.
+    Si necesitas hacer alguna tarea más pesada ---como llevar la bitácora de eventos o enviar un correo electrónico--- debes registrar una clase externa como un escucha o suscriptor de eventos y darle acceso a todos los recursos que necesites. Para más información, consulta :doc:`/cookbook/doctrine/event_listeners_subscribers`.
 
 Extensiones *Doctrine*: ``Timestampable``, ``Sluggable``, etc.
 --------------------------------------------------------------
 
 *Doctrine* es bastante flexible, y dispone de una serie de extensiones de terceros que te permiten realizar fácilmente tareas repetitivas y comunes en tus entidades.
-Estas incluyen cosas tales como ``Sluggable``, ``Timestampable``, ``registrable``, ``traducible`` y ``Tree``.
+Estas incluyen cosas tales como ``Sluggable``, ``Timestampable``, ``Loggable``, ``Translatable`` y ``Tree``.
 
 Para más información sobre cómo encontrar y utilizar estas extensiones, ve el artículo sobre el uso de :doc:`extensiones comunes de Doctrine </cookbook/doctrine/common_extensions>`.
 

_sources/book/from_flat_php_to_symfony2.txt

@@ -331,7 +331,7 @@ Como controlador frontal, :file:`index.php` ha asumido un papel completamente nu
 
    Otra ventaja del controlador frontal es la flexibilidad de las *URL*. Ten en cuenta que la *URL* a la página ``show`` del *blog* se puede cambiar de ``/show`` a ``/read`` cambiando el código solamente en una única ubicación. Antes, era necesario cambiar todo un archivo para cambiar el nombre. En *Symfony2*, incluso las *URL* son más flexibles.
 
-Por ahora, la aplicación ha evolucionado de un único archivo *PHP*, a una estructura organizada y permite la reutilización de código. Debes estar feliz, pero aún lejos de estar satisfecho. Por ejemplo, el sistema de "enrutado" es voluble, y no reconoce que la página ``list`` (``/index.php``) también debe ser accesible a través de ``/`` (si has agregado las reglas de reescritura de *Apache*). Además, en lugar de desarrollar el *blog*, una gran cantidad del tiempo se ha gastado trabajando en la "arquitectura" del código (por ejemplo, el enrutado, invocando controladores, plantillas, etc.) Se tendrá que gastar más tiempo para manejar la presentación de formularios, validación de entradas, registro de sucesos y seguridad.
+Por ahora, la aplicación ha evolucionado de un único archivo *PHP*, a una estructura organizada y permite la reutilización de código. Debes estar feliz, pero aún lejos de estar satisfecho. Por ejemplo, el sistema de "enrutado" es voluble, y no reconoce que la página ``list`` (``/index.php``) también debe ser accesible a través de ``/`` (si has agregado las reglas de reescritura de *Apache*). Además, en lugar de desarrollar el *blog*, una gran cantidad del tiempo se ha gastado trabajando en la "arquitectura" del código (por ejemplo, el enrutado, invocando controladores, plantillas, etc.) Se tendrá que gastar más tiempo para manejar el envío de formularios, validación de entradas, llevar la bitácora de sucesos y la seguridad.
 ¿Por qué tienes que reinventar soluciones a todos estos problemas rutinarios?
 
 Añadiendo un toque *Symfony2*

_sources/book/page_creation.txt

@@ -753,7 +753,7 @@ Además, observa que cada entorno carga su propio archivo de configuración. Con
 
         // ...
 
-La clave ``imports`` es similar a una declaración ``include`` *PHP* y garantiza que en primer lugar se carga el archivo de configuración principal (:file:`config.yml`). El resto del archivo de configuración predeterminado aumenta el registro de eventos y otros ajustes conducentes a un entorno de desarrollo.
+La clave ``imports`` es similar a una declaración ``include`` *PHP* y garantiza que en primer lugar se carga el archivo de configuración principal (:file:`config.yml`). El resto del archivo de configuración predeterminado aumenta el registro en la bitácora de eventos y otros ajustes conducentes a un entorno de desarrollo.
 
 Ambos entornos ``prod`` y ``test`` siguen el mismo modelo: cada uno importa el archivo de configuración básico y luego modifica sus valores de configuración para adaptarlos a las necesidades específicas del entorno. Esto es sólo una convención, pero te permite reutilizar la mayor parte de tu configuración y personalizar sólo piezas puntuales entre entornos.
 

_sources/book/testing.txt

@@ -131,7 +131,7 @@ Por ejemplo, la *edición estándar de Symfony2* proporciona una sencilla prueba
     Para ejecutar tus pruebas funcionales, la clase ``WebTestCase`` arranca el núcleo de tu aplicación. En la mayoría de los casos, esto sucede automáticamente.
     Sin embargo, si tu núcleo se encuentra en un directorio no estándar, deberás modificar tu archivo ``phpunit.xml.dist`` para ajustar la variable de entorno ``KERNEL_DIR`` al directorio de tu núcleo::
 
-        <phpunit
+        <phpunit>
             <!-- ... -->
             <php>
                 <server name="KERNEL_DIR" value="/path/to/your/app/" />

_sources/components/dependency_injection/definitions.txt

@@ -56,8 +56,6 @@ Clase
 
 En primer lugar es la clase de una definición, ésta es la clase del objeto devuelto cuando solicitas el servicio desde el contenedor.
 
-Posiblemente quieras cambiar la clase utilizada por una definición, si por ejemplo, hay funciones que sólo se pueden utilizar si existe un servicio de otro paquete, entonces puedes tener una clase que use ese otro servicio y uno que no lo hace. El primero no podría utilizar el servicio y luego con la funcionalidad adicional intercambiada usando un pase del compilador si el otro servicio esta disponible.
-
 Para determinar qué clase dicta la definición::
 
     $definition->getClass();

_sources/components/http_foundation/sessions.txt

@@ -420,7 +420,7 @@ Cuando se crea una nueva sesión, significa que *Symfony2* emite una nueva ``coo
 Tiempo de inactividad/Mantener viva la sesión
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A menudo hay circunstancias en las que posiblemente quieras proteger, o reducir al mínimo el uso no autorizado de una sesión cuando un usuario se retira de su terminal mientras está conectado destruyendo la sesión después de cierto período de tiempo de inactividad. Por ejemplo, es común que las aplicaciones de banca cierren la sesión después de sólo 5 a 10 minutos de inactividad. Ajustar la duración de la ``cookie`` aquí no es apropiado debido a que el cliente la puede manipular, por lo que debemos hacer la expiración de lado del servidor. La forma más fácil es implementarla a través de la recolección de basura la cual se ejecuta con razonable frecuencia. El ``lifetime`` de la ``cookie`` se establece a un valor relativamente alto, y la recolección de basura ``maxlifetime`` se establecería para destruir sesiones en cualquiera que sea el período de inactividad deseado.
+A menudo hay circunstancias en las que posiblemente quieras proteger, o reducir al mínimo el uso no autorizado de una sesión cuando un usuario se aleja de su terminal mientras está conectado destruyendo la sesión después de cierto período de tiempo de inactividad. Por ejemplo, es común que las aplicaciones de banca cierren la sesión después de sólo 5 a 10 minutos de inactividad. Ajustar la duración de la ``cookie`` aquí no es apropiado debido a que el cliente la puede manipular, por lo que debemos hacer la expiración de lado del servidor. La forma más fácil es implementarla a través de la recolección de basura la cual se ejecuta con razonable frecuencia. El ``lifetime`` de la ``cookie`` se establece a un valor relativamente alto, y la recolección de basura ``maxlifetime`` se establecería para destruir sesiones en cualquiera que sea el período de inactividad deseado.
 
 La otra opción es comprobar específicamente si una sesión ha caducado después de haber iniciado la sesión. La sesión se puede destruir si es necesario. Este método de procesamiento puede permitir la integración de la expiración de sesiones en la experiencia del usuario, por ejemplo, visualizando un mensaje.