diff --git a/book-content/es/2-getting-started/1-install-instructions.markdown b/book-content/es/2-getting-started/1-install-instructions.markdown
index b2bf357a..4a66d4bc 100644
--- a/book-content/es/2-getting-started/1-install-instructions.markdown
+++ b/book-content/es/2-getting-started/1-install-instructions.markdown
@@ -1,29 +1,31 @@
-# Comenzando
+# Comenzando a trabajar
* Esto será una tabla de contenidos (este texto será pegado).
{:toc}
-Necesitaremos instalar Merb para usar la plataforma.
-Claro, antes de que instalemos Merb necesitarás tener instalado un compilador C, Ruby y
-[RubyGems][], y una base de datos (si quieres hacer tus modelos persistentes).
+Se necesita instalar Merb para usar la plataforma.
+De todas maneras, antes de instalar Merb,
+usted necesitará tener instalado un compilador C, Ruby y [RubyGems][],
+y una base de datos (si usted desea hacer sus modelos persistentes).
## OS X
### Prerequisitos
-Necesitarás instalar XCode del CD OS X o descargarle del
+Necesitará instalar XCode (conocido como las Herramientas de Desarrollo)
+del DVD del sistema operativo OS X o descargarlo directamente del
[sitio web para desarrolladores de Apple][].
### Ruby & RubyGems
-Si tienes OS X 10.5 (Leopard), es muy probable que tengas ya Ruby instalado.
+En el caso que usted tenga instalado en su sistema OS X 10.5 (Leopard),
+entonces su sistema ya cuenta con Ruby instalado y listo para su uso.
### Merb
$ sudo gem install merb
-
## Linux
-Las siguientes instrucciones son para distribuciones basadas en Debian ([Ubuntu][], por
-ejemplo) que usen el manejador de paquetes apt-get.
-Si estás usando una distribución diferente, usa el manejador de paquetes de tu distribución
+Las siguientes instrucciones son para aquellas distribuciones basadas en [Debian][]
+([Ubuntu][], por ejemplo) que usen el manejador de paquetes apt-get.
+Si usted utiliza una distribución diferente, use el manejador de paquetes de su distribución
(por ejemplo, los sistemas [RedHat][] usan yum como su manejador de paquetes).
### Prerequisitos
@@ -45,41 +47,42 @@ Si estás usando una distribución diferente, usa el manejador de paquetes de tu
$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
$ sudo gem update --system
-
### Merb
$ sudo gem install merb
-
## Windows
Los usuarios de Windows tienen un par de opciones para instalar Ruby and RubyGems.
Una manera es descargar los binarios de Ruby, instalarlos, y luego instalar RubyGems.
-Una alternativa es usar el [One-Click Ruby Installer][] que viene empaquetado con RubyGems
-(y algunas otras cosas).
-Si usas el One-Click Installer, asegúrate de seleccionar la opción 'Enable RubyGems' en el
-wizard de instalación.
+Una alternativa es usar el [One-Click Ruby Installer][]
+que viene empaquetado con RubyGems (y algunas otras cosas).
+Si usted utiliza el One-Click Installer,
+asegúrese de seleccionar la opción 'Enable RubyGems' durante la instalación.
-Por defecto te instalará Ruby en el directorio C:\Ruby.
-Una vez instalado, has lo siguiente:
+Por defecto, Ruby se instalara en el directorio C:\Ruby.
+Una vez instalado, usted debe hacer lo siguiente:
Start --> Programs --> Ruby-<version> --> RubyGems --> RubyGems Package Manager
-Esto abrirá un prompt de comando en el directorio C:\Ruby y mostrará alguna
-información sobre cómo usar. Entonces es solo a cuestión de instalar Merb:
+Esto abrirá un prompt de comando en el directorio C:\Ruby
+y mostrará alguna información sobre cómo usarlo.
+Entonces es solo a cuestión de instalar Merb:
C:\Ruby> gem install merb
-Este comando puede demorar unos minutos en ejecutarse, pues debe actualizar la cache de
-las gemas, traer todas las gemas relacionadas con Merb e instalarlas.
+Este comando puede demorar unos minutos en ejecutarse,
+pues debe actualizar la cache de las gemas,
+traer todas las gemas relacionadas con Merb e instalarlas.
-_Nota_: Si quieres usar una base de datos SQLite (es la que viene por defecto), tienes que
-descargarla e instalarla por separado. Más información puede ser encontrada en el sitio de
-[SQLite][].
+_Nota_: Si desea usar una base de datos SQLite (la cual viene por defecto),
+usted debe descargarla e instalarla por separado.
+Más información puede ser encontrada en el sitio de [SQLite][].
[sitio web para desarrolladores de Apple]: http://developer.apple.com/technology/xcode.html
-[RubyGems]: http://www.rubygems.org/
-[Ubuntu]: http://www.ubuntu.com/
-[RedHat]: http://www.redhat.com/
+[Debian]: http://www.debian.org/
+[RubyGems]: http://www.rubygems.org/
+[Ubuntu]: http://www.ubuntu.com/
+[RedHat]: http://www.redhat.com/
[One-Click Ruby Installer]: http://rubyinstaller.rubyforge.org/wiki/wiki.pl
-[SQLite]: http://www.sqlite.org/
+[SQLite]: http://www.sqlite.org/
diff --git a/book-content/es/2-getting-started/2-generate-an-application.markdown b/book-content/es/2-getting-started/2-generate-an-application.markdown
index 599b4e05..61bdfd6a 100644
--- a/book-content/es/2-getting-started/2-generate-an-application.markdown
+++ b/book-content/es/2-getting-started/2-generate-an-application.markdown
@@ -3,83 +3,92 @@
* Esto será una tabla de contenidos (este texto será pegado).
{:toc}
-Merb viene con un generador (merb-gen) para crear aplicaciones Merb. El generador
-puede generar diferentes tipos aplicaciones Merb, para ver todas las opciones del generador
-usa
+Merb viene con un generador (``merb-gen``)
+para crear aplicaciones.
+Este generador puede crear diferentes tipos aplicaciones;
+para ver todas las opciones del mismo,
+escriba en la linea de comandos
- $ merb-gen -h
+ $ merb-gen -H
+{:lang=shell html_use_syntax=true}
-Por ahora, limitémonos solamente a los tipos de aplicaciones Merb que se pueden generar.
+Por ahora, limitémonos solamente a los tipos de aplicaciones Merb
+que pueden ser generadas a través del mismo.
## Tipos
Merb puede ser usado para desarrollar desde aplicaciones consistentes en un solo archivo,
muy pequeñas y rápidas hasta grandes y complejos web services.
Diferentes estructuras para la aplicación pueden generarse, dependiendo de las necesidades
del desarrollador.
-
-Las diferentes estructuras para la aplicación que puedes generar son app para una
-stack, core para un núcleo, flat para aplicaciones planas, y
-very_flat para aplicaciones muy planas.
+Las diferentes estructuras que usted puede generar
+son ``app``, ``core``, ``flat`` y ``very_flat``.
### App (stack)
El stack dogmático de Merb.
-Esto genera una estructura de directorios completa para la aplicación con un conjunto
-completo de archivos de configuración.
-También adiciona un archivo config/dependancies.rb que incluye todo el
-merb-more y DataMapper.
+Esta opción genera una estructura de directorios completa para una aplicación
+con un conjunto completo de archivos de configuración.
+También agrega el archivo ``config/dependancies.rb``
+que incluye las todas las librerías contenidas en ``merb-more`` y ``DataMapper``.
$ merb-gen app my-application
+{:lang=shell html_use_syntax=true}
-Esta aplicación tiene todo lo necesario para comenzar a construir una aplicación web
-completa; es la más similar a la estructura típica de Rails.
-Mucho en este libro funcionará con la suposición de que has comenzado de esta manera.
+Esta aplicación contiene todo lo necesario
+para comenzar a construir una aplicación web de primer nivel;
+la cual es muy similar a la estructura típica de una aplicación Rails.
+Este libro parte de la suposición
+de que usted ha comenzado a desarrollar una aplicación de este tipo.
-Arranca esta aplicación ejecutando merb en el directorio raiz de la aplicación.
+Inicie esta aplicación ejecutando ``merb``
+en el directorio raíz de la aplicación.
Esto iniciará Merb y lo pondrá a escuchar en el puerto por defecto 4000.
-Para ver tu aplicación en acción, visita [http://localhost:4000/][].
+Para ver su aplicación en acción,
+visita en su navegador web.
### Core (núcleo)
-Core generará una estructura de directorios completa para la aplicación con un conjunto
-completo de archivos de configuración.
-A diferencia de app -- la stack completa dogmática -- ninguna dependencia se
-adicionará.
+Core generará una estructura de directorios completa para una aplicación
+con un conjunto completo de archivos de configuración.
+A diferencia de la opción ``app`` -- el stack dogmática y completo --
+ninguna dependencia será agregada a la aplicación.
- $ merb-gen core my-apliccation
+ $ merb-gen core my-application
+{:lang=shell html_use_syntax=true}
-Arranca esta aplicación ejecutando merb en el directorio raiz de la aplicación.
-Fíjate que, a diferencia de las otras tres aplicaciones generadas, en core no existe
-contenido por defecto.
-Visitando [http://localhost:4000/][] generará un error hasta que adiciones contenido y
-ruteo.
+Inicie esta aplicación ejecutando ``merb``
+en el directorio raíz de la aplicación.
+Fíjese que, a diferencia de las otras tres aplicaciones generadas,
+en core no existe contenido por defecto definido.
+Visitando en su navegador web
+generará un error hasta que adicione contenido y lo enrute.
### Flat (plana)
-Una aplicación plana mantiene toda su lógica en un solo archivo, pero tiene archivos
-separados para configuración y un directorio propio para las vistas.
+Una aplicación plana mantiene toda su lógica en un solo archivo,
+pero tiene archivos de configuración separados y un directorio propio para las vistas.
$ merb-gen flat my-application
+{:lang=shell html_use_syntax=true}
-Las aplicaciones planas son arrancadas, como cualquier otra aplicación merb generada,
-ejecutando merb en el directorio raiz de la aplicación.
-Por defecto, todos los métodos en la clase my-application serán tratados como
-acciones con my-application como el controlador. e.g.:
-[http://localhost:4000/my-application/foo][]
+Este tipo de aplicación se inicializa, como cualquier otra aplicación generada por Merb,
+ejecutando ``merb`` en el directorio raíz de la aplicación.
+Por defecto, todos los métodos en la clase ``my-application``
+serán tratados como acciones con ``my-application`` como el controlador.
+Por ejemplo:
-Esto invocará MyApplication#foo y mostrará la salida desde la plantilla
-foo.html.*.
+Esto invocará ``MyApplication#foo``
+y creará la salida desde la plantilla ``foo.html.*``.
### Very Flat (muy plana)
-A aplicación muy plana es similar a otros micro frameworks de Ruby, donde la aplicación
-completa esta en un solo archivo.
+Este tipo de aplicación es similar a otros micro plataformas de Ruby,
+donde la aplicación completa se ubica en un solo archivo.
$ merb-gen very_flat my-applcation
+{:lang=shell html_use_syntax=true}
-Para arrancar una aplicación muy plana, inicia Merb con el siguiente comando (en el
-directorio de tu aplicación):
-
- $ merb -I my-applcation.rb
+Para ejecutar una aplicación muy plana, inicia Merb con el siguiente comando
+(en el directorio de tu aplicación):
-Esto arrancará Merb y lo pondrá a escuchar en el puerto por defecto (4000). Para ver tu
-aplicación en accionn, visita [http://localhost:4000/][].
+ $ merb -I my-application.rb
+{:lang=shell html_use_syntax=true}
-[http://localhost:4000/]: http://localhost:4000/
-[http://localhost:4000/my-application/foo]: http://localhost:4000/my-application/foo
+Esto arrancará Merb y lo pondrá a escuchar en el puerto por defecto (4000).
+Para ver tu aplicación en acción, visita en su navegador web.
diff --git a/book-content/es/2-getting-started/3-project-structure.markdown b/book-content/es/2-getting-started/3-project-structure.markdown
index 0f1422bc..c34d7101 100644
--- a/book-content/es/2-getting-started/3-project-structure.markdown
+++ b/book-content/es/2-getting-started/3-project-structure.markdown
@@ -3,8 +3,8 @@
* Esto será una tabla de contenidos (este texto será pegado).
{:toc}
-La estructura típica de una aplicación Merb nueva (generada con merb-gen app)
-lucirá más o menos así:
+La estructura típica de una nueva aplicación Merb (generada con el comando ``merb-gen app``)
+es definida más o menos así:
Directorio de la aplicación (Merb.root)
- app
@@ -27,102 +27,115 @@ lucirá más o menos así:
- spec
- tasks
-Hagamos un breve resumen de cada directorio y su función.
+A continuación se presentará una síntesis de cada directorio y su función especifica.
## app
-Este directorio es donde emplearás la mayor parte de tu tiempo, dado que contiene las
-"entrañas" de tu aplicación Merb.
+Este directorio es donde usted empleará la mayor parte de su tiempo,
+dado que contiene las "entrañas" de su aplicación Merb.
### controllers
-Todos los controladores de tu aplicación son almacenados aquí (esto no supone sorpresa).
-Los controladores son típicamente nombrados en plural.
-Por ejemplo, si tienes un modelo "Page", el archivo del controlador normalmente se
-llamará pages.rb.
-Esto es simplemente una convención, al fin y al cabo; tu eres libre de nombrar tus
-controladores como más te guste.
-Visita la sección [controladores][] para más información.
+Todos los controladores de su aplicación son almacenados aquí (lo cual no supone sorpresa alguna).
+Los controladores son generalmente nombrados en plural.
+Por ejemplo, si tiene un modelo llamado "``Pagina``",
+entonces el archivo del controlador debería de llamarse ``paginas.rb``.
+Esto es simplemente una convención, de todas maneras;
+usted es libre de nombrar sus controladores a su conveniencia.
+Visite la sección [controladores][] para más información.
### models
-Este directorio contiene las clases de tus modelos.
-Estas clases típicamente sirven como tu [ORM][], que proveen acceso orientado a objecto a
-tus tablas en la base de datos.
-Visita la sección [modelos][] para más información.
+Este directorio contiene las clases de sus modelos.
+Estas clases típicamente sirven como su [ORM][],
+que proveen acceso orientado a objeto a sus tablas en la base de datos.
+Visite la sección [modelos][] para más información.
### views
-Cualquier plantilla para las vistas se almacenarán aquí.
-Por defecto, este directorio contiene los subdirectorios exceptions y
-layout.
-El directorio exceptions almacena plantillas que están generalmente relacionadas a
-errores HTTP.
-Por ejemplo, una aplicación Merb nueva contendrá una vista
-not_found.html.{erb,haml}, que corresponde al código de estado 404 de HTTP.
-El directorio layout contiene las plantillas sobretodo de la aplicación, dentro de
-las que las plantillas de las acciones pueden ser mostradas.
-El archivo layout por defecto de la aplicación se llama
-application.html.{erb,haml}.
-Visita la sección [vistas][] para más información.
+Cualquier plantilla para las vistas serán almacenadas aquí.
+Por defecto, este directorio contiene los
+subdirectorios ``exceptions`` y ``layout``.
+El primero almacenará plantillas
+que están generalmente relacionadas a errores HTTP.
+Por ejemplo, una nueva aplicación Merb
+contendrá la vista ``not_found.html.{erb,haml}``,
+que corresponde al código de estado 404 de HTTP.
+El ultimo contendrá las plantillas de la aplicación,
+dentro de las cuales solamente las plantillas de las acciones serán mostradas.
+El archivo de presentación por defecto de la aplicación
+se llama ``application.html.{erb,haml}``.
+Visite la sección [vistas][] para más información.
## config
Si, lo adivinaste.
-Los archivos de configuration de Merb son guardados aquí.
-El archivo router.rb contiene las [rutas](/getting-started/router) URL de tu aplicación, que definen la estructura, ordednr, y apariencia de tus URLs.
-Otro archivo importante, init.rb, se encarga de la configuration base de Merb.
-Aquí es donde puedes configurar tu ORM, motor de plantillas, y plataforma de pruebas.
-También puedes adicionar configuraciones a medida al Merb::BootLoader en sus bloques before_app_loads y after_app_loads.
-Otro archivo importante, dependencies.rb, es donde puedes defindire las dependencias de tu aplicación: otras librarias o gemas que tu aplicación requiere.
-Cualquire dependencia listada en ese archivo será cargada cuando tu aplicación Merb arranca.
+Los archivos de configuración de Merb son almacenados aquí.
+El archivo ``router.rb`` contiene las [rutas][] URL de su aplicación,
+que definen la estructura, el orden y la apariencia de sus URLs.
+Otro archivo importante, ``init.rb``, se encarga de la configuración base de Merb.
+Aquí es donde puedes configurar su [ORM][], motor de plantillas, y plataforma de pruebas.
+También puede adicionar configuraciones a medida en el ``Merb::BootLoader``
+en sus bloques ``before_app_loads`` y ``after_app_loads``.
+Otro archivo importante, ``dependencies.rb``,
+es donde usted puede definir las dependencias de su aplicación:
+otras librerías o gemas que su aplicación requiere.
+Cualquier dependencia listada en ese archivo será cargada cuando su aplicación Merb arranque.
### environments
-Aquí es donde cualquier archivo de configuración específico a algun entorno son guardados.
-Aquí existen un par de archivos típicos de configuración (en Ruby puro); cada uno corresponde a un entorno (desarrollo, producción, etc.) específico de Merb.
+Aquí es donde todo archivo de configuración específico a algún entorno es guardado.
+Existen un par de archivos típicos de configuración (en Ruby puro);
+cada uno corresponde a un entorno especifico de Merb
+(desarrollo, producción, etc.).
## gems
-Cuando estés listo para [desplegar][] tu aplicación, es recomendable que
-[empaquetes][] todos tus dependencias dentro del directorio de la aplicación.
-El directorio gems es donde estas dependencias empaquetadas serán almacenadas.
-Cuando inicies la aplicación Merb, esta cargará cualquier gema desde este directorio, priorizándolas a las gemas del sistema.
+Cuando usted esté listo para el [despliegue][] su aplicación,
+es recomendable que [empaquete][] todas sus dependencias
+dentro del directorio de la aplicación.
+El directorio ``gems`` es donde estas dependencias empaquetadas
+serán almacenadas.
+Cuando inicie su aplicación,
+Merb cargará cada gema guardada en este directorio, otorgandoles prioridad por sobre las gemas del sistema.
## public
-Aquí es donde puedes almacenar archivos "estáticos", tales como los archivos favicon.ico y robots.txt.
+Aquí es donde usted puede almacenar los archivos "estáticos",
+tales como ``favicon.ico`` y ``robots.txt``.
### images
-Cualquier imagen que tus plantillas pueden usar deberán ir aquí.
+Cualquier imagen que sus plantillas utilicen deberán ser almacenadas aquí.
### javascripts
-En la "Merb stack" típica, este directorio contiene dos archivos: application.js y jquery.js.
-La Merb stack por defecto viene empaquetada con la poderosa plataforma JavaScript
-[jQuery][].
+En el típico "stack", este directorio contiene dos archivos:
+``application.js`` y ``jquery.js``.
+El stack por defecto viene empaquetado
+con la poderosa plataforma JavaScript llamada [jQuery][].
-Si tienes cantidades pequeñas de código JavaScript específico a tu aplicación, deberá ir
-dentro del archivo application.js.
-Si resulta que esto se demuestra inviable, puedes adicionar más archivos según necesites.
+Si usted tiene pequeñas cantidades de código JavaScript específico a su aplicación,
+entonces resulta apropiado incluirlo dentro del archivo ``application.js``.
+Si esto no es posible, entonces puede adicionar más archivos según sus necesidades.
### stylesheets
-Siguiendo la idea de la separación de intereses, cualquier estilismo visual deberá ser
-puesto en una hoja de estilos.
-Cuando generás una aplicación Merb, se crea un archivo de hoja de estilos (llamado
-master.css), que puedes ajustar a tus deseos.
+Siguiendo la idea de la separación de intereses,
+cualquier estilismo visual deberá ser definido en una hoja de estilos.
+Cuando usted genera una aplicación Merb,
+el generador crea un archivo de hoja de estilos (llamado ``master.css``),
+el cual usted puede ajustar según sus necesidades.
## spec
-Si estás usando [rspec][] como tu plataforma de [pruebas][], este directorio contendrá estos
-tests.
-Por defecto, este directorio contiene dos archivos: un archivo spec.opts vacio, qu
- puedes usara para adicionar argumentos por linea de comandos a rspec (añadir salida
-coloreada, etc.) y spec_helper.rb, que es donde puedes ajustar a conveniencia el
-spec runner que utilices (entre otras cosas).
+Si estás usando [RSpec][] como tu plataforma de [pruebas][],
+este directorio contendrá todos los archivos de pruebas.
+Por defecto, este directorio contiene dos archivos:
+el archivo ``spec.opts`` vacío,
+el cual usted puede usar para adicionar argumentos por linea de comandos a RSpec
+(añadir salida coloreada, etc.) y ``spec_helper.rb``,
+el cual usted puede ajustar a conveniencia el spec runner que utilice (entre otras cosas).
## tasks
-Este directorio contiene las tareas de [thor][] de Merb.
-
-
-[empaquetar]: /deployment/bundle
-[controladores]: /getting-started/controllers
-[desplegar]: /deployment
-[jQuery]: http://jquery.com/
-[modelos]: /getting-started/models
-[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping
-[rutas]: /getting-started/router
-[RSpec]: http://rspec.info/
-[probando]: /testing-your-application
-[thor]: http://wiki.merbivore.com/faqs/thor
-[vistas]: /getting-started/views
+Este directorio almacenará las tareas [thor][] de Merb.
+
+[empaquete]: /deployment/bundle
+[controladores]: /getting-started/controllers
+[despliegue]: /deployment
+[jQuery]: http://jquery.com/
+[modelos]: /getting-started/models
+[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping
+[rutas]: /getting-started/router
+[RSpec]: http://rspec.info/
+[prueba]: /testing-your-application
+[thor]: http://wiki.merbivore.com/faqs/thor
+[vistas]: /getting-started/views
diff --git a/book-content/es/2-getting-started/4-mvc.markdown b/book-content/es/2-getting-started/4-mvc.markdown
index b16c28bf..482766b7 100644
--- a/book-content/es/2-getting-started/4-mvc.markdown
+++ b/book-content/es/2-getting-started/4-mvc.markdown
@@ -3,68 +3,66 @@
* Esto será una tabla de contenidos (este texto será pegado).
{:toc}
-MVC es un acrónimo que quiere decir Modelo, Vista, Controlador.
-Describe una estructura de aplicaciones web que es fácil de mantener y
-a la que es fácil hacer pruebas porque
-separa la lógica de negocio, lógica de servidor y la generación de contenido.
-Esta es la estructura de una aplicación standard Merb que es generada por el
-comando '``merb-gen app``'.
-Es esta también la estructura usada por [Rails][], [CakePHP][], [Django][],
-y muchas otras plataformas de desarrollo web.
+MVC es un acrónimo que significa "Modelo, Vista, Controlador".
+Describe una manera de estructurar una aplicación web
+que es fácil de probar y mantener
+debido a que separa la lógica de negocio, lógica de servidor y la generación de contenido.
+Esta es la estructura de una aplicación standard Merb
+que es generada por el comando '``merb-gen app``'.
+Es también la estructura adoptada por [Rails][], [CakePHP][], [Django][],
+y muchas otras plataformas de desarrollo web populares.
-Para desarrollar de manera efectiva en Merb
-es importante que se comprenda tanto como funciona una estructura MVC,
-como la manera más efectiva de trabajar con ella.
-Este capítulo discutirá la plataforma someramente;
-los siguientes tres capítulos examinarán cada parte en detalle.
+Para desarrollar en Merb de una manera efectiva,
+es sumamente importante que uno entienda tanto el funcionamiento de una estructura MVC
+como la manera más apropiada de trabajar con ella.
+Este capítulo discutirá la plataforma en forma general;
+los siguientes tres capítulos examinarán cada pieza en detalle.
Los [Modelos][] son el núcleo de la plataforma.
-Ellos son responsables de la lógica de negocio de tu aplicación;
-en Merb los Modelos son mayormente asociados con accesos a la base de datos
+Ellos son los responsables de la lógica de negocio de su aplicación;
+en Merb, son generalmente asociados con el acceso a la base de datos
a través de un ORM tal como DataMapper o Active Record.
-Algunas veces los Modelos son usados con un ORM,
+Algunas veces los modelos son usados con un ORM,
simplemente como un envoltorio para una tabla en la base de datos.
-No obstante es generalmente considerado una buena práctica tener Modelos
-'gordos'.
-Esto significa que las clases Modelos es donde deberás mantener cosas
+No obstante es generalmente considerado una buena práctica tener modelos 'gordos'.
+Esto significa que usted debería mantener aspectos
tales como relaciones de datos y métodos
-para cada manipulación y recuperación no trivial de datos.
+para cualquier pieza no trivial de recuperación y manipulación de datos
+dentro de las clases modelos.
-Las [Vistas][] son el ostentoso cascarón exterior de una aplicación.
-Las Vistas son responsables de generar el contenido real (HTML, XML, JSON)
+Las [Vistas][] son el ostentoso cascarón exterior de su aplicación.
+Son las responsables de generar el contenido real (HTML, XML, JSON)
retornado por una petición.
-Muy tipicamente, las Vistas son escritas en un formato de plantillas
+Generalmente, estas son escritas en un formato de plantillas
tales como [Erb][] (Ruby embebido) o [Haml][].
-Los desarrolladores sabios intentarán poner tan poco código como sea posible en
-sus Vistas.
+Aquellos desarrolladores lo suficientemente sabios intentarán incluir tan poco
+código como sea posible dentro sus vistas.
Los [Controladores][] se encargan de recibir una petición entrante
-y convertirla en una respuesta.
+y de convertirla en una respuesta.
Son responsables de interpretar la petición entrante,
-obtener instancias de los Modelos necesarios,
-y pasar esta información a la Vista.
+obtener instancias de los modelos necesarios,
+y pasar esta información a través de la vista.
-En una aplicación Merb típica,
-el código para cada una de estas partes se encuentra
+En una típica aplicación Merb,
+el código para todas estas tres partes se encuentra
en directorios del mismo nombre dentro del directorio '``app``'.
-En los siguientes capítulos examinaremos como Merb implementa cada una de estas
-partes.
+En los siguientes capítulos, examinaremos como Merb implementa cada una de estas partes.
-Los usuarios principiantes se sienten muchas veces tentados a adicionar mucho
-código en la capa de controladores,
-pero esto conlleva a código frágil y difícil de probar.
-En cambio se le recomienda a los desarrolladores
-mantener sus controladores tan 'ligeros' como sea posible
-poniendo el código que no está directamente relacionado con el ciclo
-petición/respuesta (o la reunión de datos) en el Modelo.
+Los principiantes suelen estar tentados por agregar
+mucho código dentro de la capa de controladores,
+que produce como consecuencia a un código frágil y difícil de probar.
+En cambio, se recomienda a los desarrolladores
+a mantener sus controladores tan 'ligeros' como sea posible
+poniendo el código que no está directamente relacionado con el ciclo petición/respuesta
+(o la reunión de datos) dentro del modelo.
+[CakePHP]: http://www.cakephp.org/
+[Django]: http://www.djangoproject.com/
+[Rails]: http://rubyonrails.org
+[Erb]: http://en.wikipedia.org/wiki/ERuby
+[Haml]: http://haml.hamptoncatlin.com/
+[Controladores]: /getting-started/controllers
+[Modelos]: /getting-started/models
+[Vistas]: /getting-started/views
-
-[CakePHP]: http://www.cakephp.org/
-[Controladores]: /getting-started/controllers
-[Django]: http://www.djangoproject.com/
-[Erb]: http://en.wikipedia.org/wiki/ERuby
-[Haml]: http://haml.hamptoncatlin.com/
-[Modelos]: /getting-started/models
-[Rails]: http://rubyonrails.org
-[Vistas]: /getting-started/views
diff --git a/book-content/es/2-getting-started/5-controllers.markdown b/book-content/es/2-getting-started/5-controllers.markdown
index f7f0c92d..44a7e391 100644
--- a/book-content/es/2-getting-started/5-controllers.markdown
+++ b/book-content/es/2-getting-started/5-controllers.markdown
@@ -4,67 +4,64 @@
{:toc}
> Un controlador es el enlace entre un usuario y el sistema.
-> Provée al usuario con datos propiciando que las vistas relevantes
-> se presenten ellas mismas en los lugares apropiados de la pantalla.
-> Provée medios para ofrecer salida al usuario presentándole menús u otros
-> medios de entrar comandos y datos.
-> El controlador recibe tal salida del usuario, la traduce en los mensajes
-> apropiados y pasa estos mensajes a una o más de las vistas.
+> Este provee al usuario de una entrada arreglando que las vistas relevantes
+> se presenten ellas mismas en los lugares apropiados de la pantalla.
+> Ademas provee medios para la salida al usuario presentándole menús u otros
+> medios para introducir comandos y datos.
+> El controlador recibe tal salida al usuario, la traduce en mensajes
+> apropiados y los redirecciona a una o más vistas.
> - [Trygve Reenskaug][]{: .quote-author}, autor del patrón de diseño
> Modelo-Vista-Controlador[^mvc-essay]
{: cite=http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf .lead-quote}
-
En el paradigma [MVC][], los controladores representan la capa de pegamento
-que conecta la lógica de negocio (Modelo) con las Vistas.
+que conecta la lógica de negocio (definida dentro de un modelo) con las vistas.
-Concretamente el controlador es responsable del mapeo de una acción del
-usuario-final con una respuesta de la aplicación.
+Concretamente, el controlador es responsable del realizar la interconexión entre
+una acción del usuario con una respuesta definida en la aplicación.
En Merb, técnicamente hablando,
-los controladores son clases que heredan de ``Merb::Controller``.
-En una aplicación Merb-stack, una clase controlador llamada ``Application`` es
-creada.
-Todos los controladores generados heredan de ``Application``;
-por ende todos comparten los mismos atributos que ``Application``.
+los controladores son clases que heredan su funcionalidad de la clase ``Merb::Controller``.
+En una aplicación stack de Merb, una clase controlador llamada ``Application`` es creada.
+Todos los controladores generados heredan de la clase recientemente mencionada;
+por ende, todos ellos comparten los mismos atributos que la misma.
La lógica del [Enrutador][] de Merb examina los detalles de la petición entrante,
-comparándolos con reglas especificadas en el archivo ``router.rb``.
-Asumiendo que una correspondencia es encontrada,
-el Enrutador entonces envía la petición al controlador y acción apropiadas.
+comparándolos contra las reglas especificadas en el archivo ``router.rb``.
+Asumiendo que una correspondencia sea encontrada,
+el enrutador entonces envía la petición al controlador y a la acción apropiadas.
En este capítulo, veremos cómo generar y organizar los controladores.
-También discutiremos cómo se pueden escribir **acciones**,
-que son los métodos del controlador que son llamados para que se encarguen de
-las peticiones entrantes.
-Finalmente veremos cómo extender las funcionalidades de un controlador.
+También discutiremos cómo escribir **acciones**,
+que son los métodos de un controlador los cuales serán llamados
+a la hora de manejar peticiones entrantes.
+Finalmente, veremos cómo extender las funcionalidades de un controlador.
## Generando controladores
-Tú puedes generar dos tipos de controladores:
+Usted puede generar dos tipos de controladores:
un controlador standard y un controlador [RESTful][].
### Un controlador standard
- $ merb-gen controller birds
- [ADDED] app/controllers/birds.rb
- [ADDED] app/views/birds/index.html.erb
- [ADDED] spec/requests/birds_spec.rb
- [ADDED] app/helpers/birds_helper.rb
+ $ merb-gen controller pajaros
+ [ADDED] app/controllers/pajaros.rb
+ [ADDED] app/views/pajaros/index.html.erb
+ [ADDED] spec/requests/pajaros_spec.rb
+ [ADDED] app/helpers/pajaros_helper.rb
{:lang=shell html_use_syntax=true}
El comando anterior genera varios archivos.
-El archivo controlador (``birds.rb``) contendrá métodos para cada acción,
+El archivo controlador (``pajaros.rb``) contendrá métodos para cada acción,
así como otros métodos que el controlador necesita.
El archivo plantilla de vista (``index.html.erb``) puede ser usado para generar HTML,
usando un procesador de ``erb`` (Ruby embebido).
-Los demás archivos (``birds_spec.rb``, ``birds_helper.rb``)
-deben ser usados para almacenar las especificaciones de las pruebas así como
-métodos helper (ayudantes).
+Los archivos restantes (``pajaros_spec.rb``, ``pajaros_helper.rb``)
+deben ser usados para contener las especificaciones de las pruebas así como los métodos de ayuda.
-Echemos un vistazo rápido al controlador generado:
+Si usted observa a simple vista el controlador generado:
- class Birds < Application
+ class Pajaros < Application
def index
render
@@ -73,170 +70,160 @@ Echemos un vistazo rápido al controlador generado:
end
{:lang=ruby html_use_syntax=true}
-El generator adicionó una nueva clase llamada ``Birds``,
-que hereda de ``Application``.
-La nueva clase tiene un método llamado ``index``.
+El generador agregó una nueva clase denominada ``Pajaros``,
+que hereda su funcionalidad básica de la clase ``Application``.
+Esta nueva clase contiene un método llamado ``index``.
En el contexto de un controlador,
-a menudo nos referimos a estos métodos como **acciones del controlador** o
-simplemente **acciones**.
-
+a este tipo de métodos se los suele denominar
+**acciones del controlador** o simplemente **acciones**.
-``Application`` (una subclase de ``Merb::Controller``)
-es la clase de la cual usualmente heredan los controladores.
-Por ello es un lugar conveniente para compartir código entre controladores.
+La clase ``Application`` (una subclase de ``Merb::Controller``)
+es de la cual usualmente heredan los controladores.
+Por esta razón, es conveniente utilizarla para compartir código entre controladores.
(_usar con precaución_)
-
+-- {: .notes}
-Si notas que cometiste un error generando tu controlador,
-puedes borrar el controlador generado adicionando ``-d`` al
-final del comando que recién enviaste:
-
- $ merb-gen controller birds -d
- [DELETED] app/controllers/birds.rb
- [DELETED] app/views/birds/index.html.erb
- [DELETED] spec/requests/birds_spec.rb
- [DELETED] app/helpers/birds_helper.rb
+Si usted se da cuenta que ha cometido un error generando su controlador,
+usted puede borrarlo agregando la opción ``-d`` al
+final del comando que ha ejecutado:
+
+ $ merb-gen controller pajaros -d
+ [DELETED] app/controllers/pajaros.rb
+ [DELETED] app/views/pajaros/index.html.erb
+ [DELETED] spec/requests/pajaros_spec.rb
+ [DELETED] app/helpers/pajaros_helper.rb
{:lang=shell html_use_syntax=true}
=--
### Un controlador REStful
- $ merb-gen resource_controller cats
- [ADDED] spec/requests/cats_spec.rb
- [ADDED] app/controllers/cats.rb
- [ADDED] app/views/cats/index.html.erb
- [ADDED] app/views/cats/show.html.erb
- [ADDED] app/views/cats/edit.html.erb
- [ADDED] app/views/cats/new.html.erb
- [ADDED] app/helpers/cats_helper.rb
+ $ merb-gen resource_controller gatos
+ [ADDED] spec/requests/gatos_spec.rb
+ [ADDED] app/controllers/gatos.rb
+ [ADDED] app/views/gatos/index.html.erb
+ [ADDED] app/views/gatos/show.html.erb
+ [ADDED] app/views/gatos/edit.html.erb
+ [ADDED] app/views/gatos/new.html.erb
+ [ADDED] app/helpers/gatos_helper.rb
{:lang=shell html_use_syntax=true}
-Si abres el archivo controlador recién generado (``app/controllers/cats.rb``),
-notarás que el generador creó un nueva clase llamada ``Cats``.
-Como era de esperar la clase hereda de ``Application``.
-Sin embargo, esta vez, en lugar de una acción ``index`` vacía,
-encontramos siete acciones completamente definidas.
+Si usted abre el archivo controlador recientemente generado (``app/controllers/gatos.rb``),
+usted notará que el generador creó un nueva clase llamada ``Gatos``.
+Como era de esperarse, la clase hereda su funcionalidad de la clase ``Application``.
+Sin embargo, esta vez, en lugar de una acción ``index`` vacía,
+se encontrara con siete acciones ya predefinidas.
-Veamos el archivo generado:
+Si usted observa a simple vista el archivo generado:
- class Cats < Application
+ class Gatos < Application
# provides :xml, :yaml, :js
def index
- @cats = Cat.all
- display @cats
+ @gatos = Gato.all
+ display @gatos
end
def show(id)
- @cat = Cat.get(id)
- raise NotFound unless @cat
- display @cat
+ @gato = Gato.get(id)
+ raise NotFound unless @gato
+ display @gato
end
def new
only_provides :html
- @cat = Cat.new
- display @cat
+ @gato = Gato.new
+ display @gato
end
def edit(id)
only_provides :html
- @cat = Cat.get(id)
- raise NotFound unless @cat
- display @cat
+ @gato = Gato.get(id)
+ raise NotFound unless @gato
+ display @gato
end
- def create(cat)
- @cat = Cat.new(cat)
- if @cat.save
- redirect resource(@cat), :message => {:notice => "Cat fue creado satisfactoriamente"}
+ def create(gato)
+ @gato = Gato.new(gato)
+ if @gato.save
+ redirect resource(@gato), :message => {:notice => "Gato fue creado exitosamente."}
else
- message[:error] = "Cat no pudo ser creado"
+ message[:error] = "Gato no pudo ser creado."
render :new
end
end
- def update(id, cat)
- @cat = Cat.get(id)
- raise NotFound unless @cat
- if @cat.update_attributes(cat)
- redirect resource(@cat)
+ def update(id, gato)
+ @gato = Gato.get(id)
+ raise NotFound unless @gato
+ if @gato.update_attributes(gato)
+ redirect resource(@gato)
else
- display @cat, :edit
+ display @gato, :edit
end
end
def destroy(id)
- @cat = Cat.get(id)
- raise NotFound unless @cat
- if @cat.destroy
- redirect resource(:cats)
+ @gato = Gato.get(id)
+ raise NotFound unless @gato
+ if @gato.destroy
+ redirect resource(:gatos)
else
raise InternalServerError
end
end
- end # Cats
+ end # Gatos
{:lang=ruby html_use_syntax=true}
-
-Wow, eso es mucho código.
Como regla general,
-tú **no** debieras usar código generado que no entiendas.
-Por suerte, el código anterior es muy fácil de entender
-y nosotros lo repasaremos en detalle.
+usted **no** debería utilizar código generado que no entienda.
+Afortunadamente, el código detallado previamente es muy simple de comprender
+y ahora procederemos a repasarlo en detalle.
-Pero antes de que revisemos el código, hablemos sobre [REST][].
+Pero antes de revisarlo, es importante hablar sobre [REST][].
## REST
-[REST][] es un acrónimo para Transferencia de Estado Representacional
-([Representational State Transfer][]).
-Fue por primera vez introducido en el 2000 por [Roy Fielding][][^rest\_intro].
-REST se refiere a un estilo de arquitectura de software que esboza cómo los
+[REST][] es el acrónimo que significa "Transferencia de Estado Representacional".
+Fue por primera vez introducido en el año 2000 por [Roy Fielding][][^rest\_intro].
+REST se refiere a un estilo de arquitectura de software que delinea cómo los
[recursos][] son definidos y accedidos.
-De esta manera son los [recursos][] los componentes claves de REST.
+Por consecuencia, los [recursos][] son los componentes claves de REST.
-**¿Qué es un recurso, en el contexto de REST?**
+**¿Qué es un recurso, dentro del contexto de REST?**
Un recurso es una fuente de información específica,
-referenciada por una URI (identificador global).
-En términos no técnicos, es cierta información que puedes acceder a travez de una
-dirección específica.
+referenciada por una [URI][] (identificador global de recursos).
+En términos prácticos, se trata de cierta información que puede
+ser accedida a través de una dirección específica.
REST usa el protocolo HTTP para comunicar datos entre los diferentes actores.
-Es a menudo usado para servicios web,
-porque sus principios aplican muy bien a recursos web.
+Es generalmente utilizado para servicios web,
+porque sus principios son aplicados coherentemente a los recursos web.
-**Aquí está cómo es que la gente usualmente mapea recursos web REST:**
+**Aquí se presenta cómo es realizada la interconexión de recursos web REST:**
-**URI:** http://site.com/cats o http://site.com/cats/1-felix
-(identificador/dirección global)
-
-**Formato:** Tipo o extensión MIME (HTML, JSON, XML, YAML, CSV, PDF, ...)
-
-**acción:** mapea los métodos HTTP (POST, GET, PUT, y DELETE) a métodos de recursos
+**URI:** http://site.com/gatos o http://site.com/gatos/1-felix
+(identificador global/dirección)
+**Formato:** tipo o extensión MIME (HTML, JSON, XML, YAML, CSV, PDF, ...)
+**Acción:** interconexión de los métodos HTTP (POST, GET, PUT, y DELETE) con los métodos de un recurso
Si un recurso es definido, Merb usa la ``URI`` y el método HTTP
para seleccionar un controlador y una acción.
-
-
-[MVC]: /getting-started/mvc
+[MVC]: /getting-started/mvc
[redirect]: http://merbivore.com/documentation/1.0/doc/rdoc/merb-core-1.0/index.html?a=M000529&name=redirect
-[Representational State Transfer]: http://en.wikipedia.org/wiki/Representational_State_Transfer
-[recursos]: http://en.wikipedia.org/wiki/Representational_State_Transfer#REST.27s_central_principle:_resources
-[REST]: http://en.wikipedia.org/wiki/Representational_State_Transfer
-[RESTful]: http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_Web_services
-[Enrutador]: /getting-started/router
-[Roy Fielding]: http://en.wikipedia.org/wiki/Roy_Fielding]
+[recursos]: http://en.wikipedia.org/wiki/Representational_State_Transfer#REST.27s_central_principle:_resources
+[REST]: http://en.wikipedia.org/wiki/Representational_State_Transfer
+[RESTful]: http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_Web_services
+[Enrutador]: /getting-started/router
+[Roy Fielding]: http://en.wikipedia.org/wiki/Roy_Fielding]
[Trygve Reenskaug]: http://en.wikipedia.org/wiki/Trygve_Reenskaug
-[View]: /getting-started/view
+[View]: /getting-started/view
+[URI]: ...
-
-[^rest\_intro]: Chapter 5 of Fielding’s dissertation is ["Representational State Transfer (REST)"](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)
-[^mvc-essay]: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
+[^rest\_intro]: Capitulo 5 de la disertación de Fielding sobre la ["Transferencia de Estados Representacionales (REST)"](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)
+[^mvc-essay]: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
-
-*[HTTP]: Hypertext Transfer Protocolo
-*[REST]: Representational state transfer
+*[HTTP]: Hypertext Transfer Protocol
+*[REST]: REpresentational State Transfer
+*[URI]: Universal Resource Identifier
diff --git a/book-content/es/2-getting-started/6-views.markdown b/book-content/es/2-getting-started/6-views.markdown
index 53cf1709..c4f7f8fc 100644
--- a/book-content/es/2-getting-started/6-views.markdown
+++ b/book-content/es/2-getting-started/6-views.markdown
@@ -1,7 +1,8 @@
-#Views
+# Vistas
+* Esto será una tabla de contenidos (este texto será pegado).
+{:toc}
+## Ayudantes para Formularios
-##Form Helpers
-
-##Date and Time Helpers
\ No newline at end of file
+## Ayudantes para Fecha y Tiempo
\ No newline at end of file
diff --git a/book-content/es/2-getting-started/7-models.markdown b/book-content/es/2-getting-started/7-models.markdown
index 94980280..228ea63c 100644
--- a/book-content/es/2-getting-started/7-models.markdown
+++ b/book-content/es/2-getting-started/7-models.markdown
@@ -1,55 +1,52 @@
-#Modelos
+# Modelos
* Esto será una tabla de contenidos (este texto será pegado).
{:toc}
-Dicho a _grosso modo_ los modelos son la representación programática
-de los conceptos y datos que una aplicación usa.
-En una aplicación de blog, estos serían cosas
-tales como artículos, comentarios y usuarios.
-En una aplicación de tienda,
-serían productos, clientes, carritos de compra, ventas, etc.
-Merb fue diseñado para dar a los desarrolladores tanta libertad como fuera
-posible describiendo sus modelos.
-Los Modelos pueden ser cualquier cosa que un desarrollador pueda representar con
-clases de Ruby.
-
-Dicho esto la gran mayoría de aplicaciones
-usarán algún tipo de [ORM][] (Object Relational Mapper)
-para hacer sus datos persistentes entre peticiones.
-La mayoría de las aplicaciones almacenarán sus datos en alguna forma de base de
-datos.
-La Stack por defecto de Merb usa [DataMapper][] para comunicarse
+Como ha sido argumentado, los modelos son la representación programática
+de los conceptos y los datos que una aplicación utiliza.
+En una aplicación de blog, estos modelos serían representaciones
+de artículos, comentarios y usuarios.
+En una aplicación de una tienda electrónica,
+los modelos representarían productos, clientes, carritos de compra, ventas, etc.
+Merb fue diseñado para dar a los desarrolladores tanta libertad como fuese posible
+a la hora de describir sus modelos para una cierta aplicación.
+Los modelos representaran cualquier cosa que un desarrollador pueda definir con clases de Ruby.
+
+Habiendo dicho esto, la gran mayoría de las aplicaciones
+usarán algún tipo de [ORM][] (Interconexionador Relacional de Objetos)
+para permitir que sus datos sean persistentes entre peticiones.
+La mayoría de las aplicaciones almacenarán sus datos en alguna forma de base de datos.
+El Stack por defecto de Merb utiliza [DataMapper][] para comunicarse
con una base de datos [SQLite][].
-Esta es una excelente opción para desarrollar fácilmente proyectos nuevos.
+Esta es una excelente opción para desarrollar fácilmente nuevos proyectos.
-Sin embargo una vez en producción
-es generalmente recomendado que los desarrolladores cambien
-a alguno de los motores base de datos más potentes,
+Una vez en producción, sin embargo,
+es generalmente recomendado que los desarrolladores utilicen
+alguno de los motores base de datos más potentes,
tales como [PostgreSQL][] o [MySQL][].
-Proyectos que vengan del mundo de Rails
-pueden querer mantener sus modelos [ActiveRecord][];
-Merb soporta esta elección también.
+Para aquellos proyectos que provienen del mundo Rails
+que deseen mantener sus modelos predefinidos en [ActiveRecord][];
+Merb también soporta esta librería para conectar a su base de datos.
-El resto de este capítulo se enfocará en el uso de DataMapper
-para crear clases Modelo.
+El resto de este capítulo se enfocará en el uso de [DataMapper][]
+para crear las clases modelo que su aplicación usará.
## Atributos
-En un modelo de DataMapper, los atributos son definidos con el método ``property``
-Este método toma el nombre del atributo, un tipo de datos,
-y un hash de opciones.
-A diferencia de ActiveRecord, un modelo de DataMapper no requiere separar
-archivos de migración (sin embargo las migraciones son soportadas).
-
-Aquí está un modelo de DataMapper standard bastante simple:
+En un modelo de [DataMapper][], los atributos son definidos a través del método ``property``.
+Este método toma el nombre de un atributo, su tipo de datos,
+y una colección de opciones.
+A diferencia de [ActiveRecord][], este tipo de modelo no requiere separar las migraciones
+en archivos separados (aunque las migraciones sean soportadas por Merb).
+A continuación se presentara un modelo standard [DataMapper][]:
class Articulo
include DataMapper::Resource
- property :id, Serial
- property :titulo, String
- property :contenido, Text
- property :publicado_el, DateTime
+ property :id, Serial
+ property :titulo, String
+ property :contenido, Text
+ property :fecha_publicacion, DateTime
end
{:lang=ruby html_use_syntax=true}
@@ -57,59 +54,57 @@ Mira la sección de [propiedades][] del sitio de DataMapper para más detalles.
## Validaciones
-Puedes hacer validaciones de los modelos de dos maneras diferentes.
-Puedes definirlas al mismo tiempo que la definición del atributo
-o usar explicitamente un método ``validates_*``.
+Usted puede puede validar sus modelos en dos maneras posibles.
+Ya sea definiendo las validaciones al mismo tiempo que la definición de un atributo
+o utilizando explícitamente el método ``validates_*``.
Los siguientes dos ejemplos son equivalentes:
- # Usando "auto-validaciones", definidas con la propiedad.
+ # Utilizando "auto-validaciones", definidas con la propiedad.
class Persona
include DataMapper::Resource
- property :id, Serial
- property :nombre, String, :nullable => false
- property :edad, Integer, :length => 1..150
+ property :id, Serial
+ property :nombre, String, :nullable => false
+ property :edad, Integer, :length => 1..150
end
# Usando los métodos "validates_*".
class Persona
include DataMapper::Resource
- property :id, Serial
+ property :id, Serial
property :nombre, String
- property :edad, Integer
+ property :edad, Integer
validates_present :nombre
- validates_length :edad, :within => 1..150
+ validates_length :edad, :within => 1..150
end
{:lang=ruby html_use_syntax=true}
-Para más information, mira la página de [validaciones][] de DataMapper.
+Para más información, referirse a la página de [validaciones][] de DataMapper.
## Asociaciones
-DataMapper tiene una manera muy versátil de definir asociaciones entre tus
-modelos.
-Todo tipo de asociaciones son soportadas, incluidos Uno-A-Muchos,
-Muchos-A-Muchos, etc.
+[DataMapper][] tiene una manera muy versátil de definir asociaciones entre sus modelos.
+Todo tipo de asociaciones son soportadas, incluidas Uno-A-Muchos, Muchos-A-Muchos, etc.
Las asociaciones son configuradas usando los métodos ``has`` y ``belongs_to``.
-Digamos por ejemplo que estás escribiendp una aplicación de blog.
-Esta aplicación tendrá los modelos Articulo y Comentario.
-Aquí vemos como definimos la asociación:
+En el caso, por ejemplo, que usted esta escribiendo una aplicación de blog.
+Esta aplicación utilizará los modelos Articulo y Comentario.
+A continuación le presentaremos como definir una asociación:
class Articulo
include DataMapper::Resource
- # Estableciendo las propiedades.
+ # Definiendo las propiedades.
has n, :comentarios
end
class Comentario
include DataMapper::Resource
- # Estableciendo las propiedades.
+ # Definiendo las propiedades.
belongs_to :articulo
end
{:lang=ruby html_use_syntax=true}
-Esto te brinda métodos para trabajar con las asociaciones.
+[DataMapper][], ademas, proporciona métodos para trabajar con las asociaciones.
articulo = Articulo.first
articulo.comentarios # Devuelve todos los comentarios asociados.
@@ -117,15 +112,15 @@ Esto te brinda métodos para trabajar con las asociaciones.
comentario.articulo # Devuelve el Articulo padre.
{:lang=ruby html_use_syntax=true}
-Si miras el modelo Articulo,
-notarás la "mítica, mágica ``n``".
+Si usted observa el modelo Articulo previamente definido,
+notará la "mítica y mágica ``n``".
Este método es un atajo de ``Infinito``
-y es usado para proveer la asociación "tiene muchos" (has many).
+y es utilizado para proveer la asociación "tiene muchos" (has many).
Configurar una asociación "tiene uno" (has one) es
tan simple como pasar el entero ``1`` (uno) al método ``has``.
-For ejemplo:
+Por ejemplo:
class Persona
include DataMapper::Resource
@@ -141,29 +136,29 @@ For ejemplo:
{:lang=ruby html_use_syntax=true}
Como la asociación ``has many`` en Rails,
-estas asociaciones provéen algunos métodos de ayuda (helper):
+estas asociaciones proveen algunos métodos de ayuda:
persona = Persona.first
persona.taza_de_cafe # Devuelve la taza de la persona.
taza = TazaDeCafe.first
- taza.persona # Devuelve el dueño de la taza.
+ taza.persona # Devuelve el dueño de la taza.
{:lang=ruby html_use_syntax=true}
-Para ejemplos más complicados, tales como ``has many through`` (tiene muchos a
-travez), refiérete a la página de DataMapper sobre [asociaciones][].
+Para observar ejemplos más complicados, tales como ``has many through`` (tiene muchos a través),
+usted debe referirse a la página de DataMapper sobre [asociaciones][].
## Callbacks
-Los Callbacks te permiten "conectarte" a varios métodos,
+Los Callbacks le permiten "engancharse" a varios métodos,
para proveer funcionalidad adicional
-o (por ejemplo) asegurar que una propiedad tiene cierto formato.
-DataMapper soporta callbacks usando un enfoque [orientado a aspecto][]
+o (por ejemplo) asegurar que una propiedad esta definida con un cierto formato.
+[DataMapper][] soporta callbacks usando un enfoque [orientado a aspecto][]
e incluye (entre otros) los métodos ``before`` y ``after``.
-Digamos que tienes un modelo Comentario.
-Quieres asegurar que la propiedad ``pagina_inicio`` comienza con "http://",
-sin tener que exigir que la persona la provea explícitamente.
-Esta es una manera de lograrlo:
+En el caso de que usted tenga un modelo Comentario, por ejemplo.
+Usted quiere asegurarse que la propiedad ``pagina_inicio`` comience con "http://",
+sin tener que exigir que un usuario la provea explícitamente.
+A continuación se le muestra una manera de implementar este requisito:
class Comentario
include DataMapper::Resource
@@ -181,29 +176,27 @@ Esta es una manera de lograrlo:
end
{:lang=ruby html_use_syntax=true}
-Como puedes ver, el método ``before`` toma (como símbolos)
-el nombre del método al que te estás "conectando"
+Como puede observar, el método ``before`` toma (traducidos como símbolos)
+el nombre del método al que usted se está "enganchando"
y el nombre del método que hará el trabajo.
-puedes también pasar un bloque:
+Usted también puede proporcionar un bloque:
before :save do
# ... el baile del mono.
end
{:lang=ruby html_use_syntax=true}
-puedes definir callbacks para cualquier método, incluidos métodos de clase.
-Para más detalles, refiérete a la página de DataMapper sobre [hooks][].
-
-
-
-[ActiveRecord]: http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29
+Usted puede definir callbacks para cualquier método, incluidos los métodos de una clase.
+Para más detalles, por favor referirse a la página de DataMapper sobre [enganches][].
+
+[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping
+[ActiveRecord]: http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29
+[DataMapper]: http://datamapper.org/doku.php
+[MySQL]: http://en.wikipedia.org/wiki/MySQL
+[PostgreSQL]: http://en.wikipedia.org/wiki/PostgreSQL
+[SQLite]: http://www.sqlite.org/
+[propiedades]: http://datamapper.org/doku.php?id=docs:properties
+[validaciones]: http://datamapper.org/doku.php?id=docs:validations
[orientado a aspecto]: http://en.wikipedia.org/wiki/Aspect_oriented
-[asociaciones]: http://datamapper.org/doku.php?id=docs:associations
-[DataMapper]: http://datamapper.org/doku.php
-[hooks]: http://datamapper.org/doku.php?id=docs:hooks
-[MySQL]: http://en.wikipedia.org/wiki/MySQL
-[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping
-[PostgreSQL]: http://en.wikipedia.org/wiki/PostgreSQL
-[propiedades]: http://datamapper.org/doku.php?id=docs:properties
-[SQLite]: http://www.sqlite.org/
-[validaciones]: http://datamapper.org/doku.php?id=docs:validations
+[asociaciones]: http://datamapper.org/doku.php?id=docs:associations
+[enganches]: http://datamapper.org/doku.php?id=docs:hooks
diff --git a/book-content/es/2-getting-started/8-request-path.markdown b/book-content/es/2-getting-started/8-request-path.markdown
index 01d5c182..5cb2d831 100644
--- a/book-content/es/2-getting-started/8-request-path.markdown
+++ b/book-content/es/2-getting-started/8-request-path.markdown
@@ -1,134 +1,123 @@
-# Camino de una petición
+# Camino de una Petición
* Esto será una tabla de contenidos (este texto será pegado).
{:toc}
-Todas las aplicaciones web actúan en respuesta a una petición HTTP por un
-cliente.
-Cada acción termina con una respuesta desde el servidor HTTP.
-En este capítulo, seguiremos el flujo del programa
-desde la petición del cliente hasta la respuesta.
+Todas las aplicaciones web actúan en respuesta a una petición HTTP realizada por un cliente.
+Cada acción termina con una respuesta proporcionada por el servidor HTTP.
+En este capítulo, se presentara el flujo de programa a seguir
+desde la petición del cliente hasta la respuesta otorgada por el servidor.
-## Desde el Cliente hasta nuestra Puerta
+## Del cliente a nuestra puerta
-Los funcionamientos internos de la Internet están más alla el alcance of este
-libro.
-Sin embargo es útil recordar
-que existe un cliente (eg, un navegador web) ahí afuera
-y que la petición que genera pasa a travez de un número
-de entidades (eg, proxies, caches, firewalls) para alcanzar nuestros servidores.
+La manera de como funciona internamente la Internet están fuera del alcance de este libro.
+Pero, sin embargo, es sumamente útil recordar
+que existe un cliente (por ejemplo, un navegador web) que será utilizado
+para generar una petición que pasara a través de un número
+de entidades (proxies, caches, firewalls, entre otras) para alcanzar un determinado servidor.
Cualquiera de estas entidades puede examinar la petición, modificarla,
-y posiblemente almacenar lo que devolvamos.
-Si todo va bien, esto será transparente al usuario
-y de ninguna importancia para el servidor.
+y posiblemente almacenar el resultado que retorne este servidor.
+En el mejor de los casos, estas acciones serán transparentes al usuario
+y de ninguna importancia para el servidor en cuestión.
-Existen situaciones sin embargo (particularmente con sitios dinámicos),
-donde estas actividades necesitarán ser tomadas en cuenta.
-Existen también maneras para sacar ventaja de la infraestructura de la Internet
-para reducir la carga en el servidor.
-Esto puede ahorranos tanto ancho de banda como costos en equipamiento.
+Sin embargo, pueden existir determinadas situaciones (particularmente con sitios dinámicos),
+donde estas acciones necesitarán de ser tomadas en cuenta.
+También existen maneras para obtener ventaja de la infraestructura de la Internet
+para reducir la carga a realizar en el servidor.
+Esto puede producir ahorros tanto en el ancho de banda como en los costos en equipamiento.
## Proxy Inverso (opcional)
-La primera parada para una petición en una aplicación
-es usualmente un proxy inverso (reverse proxy) tales como [NginX][] o el
-[mod\_proxy][] de [Apache][]
+La primera parada a realizar por una petición en una aplicación en funcionamiento
+es usualmente un proxy inverso tales como el [NginX][] o el [mod\_proxy][] de [Apache][].
Dependiendo de la configuración, estos proxies pueden servir archivos estáticos
-(eg, imágenes, hojas de estilo CSS, código JavaScript, videos).
-Muchas veces, incluso permitiremos al proxy servir páginas cacheadas
-sin siquiera interactuar con nuestra aplicación.
+(pro ejemplo imágenes, hojas de estilo CSS, código JavaScript o videos).
+Frecuentemente, se le permite al proxy servir páginas cacheadas
+sin siquiera interactuar con su aplicación web.
[Phusion Passenger][] no es un proxy inverso, _per se_.
-Sin embargo, en aras del nuestro argumento pretendamos que sí lo es.
-(Especificamente, que recibirá la petición a travez de Apache
-y que enviará una petición [Rack][] al servidor de la aplicación.)
+Sin embargo, en aras del nuestro argumento, se pretenderá que sí lo es.
+(Específicamente, este recibirá una petición a través del servidor [Apache][]
+y consecuentemente enviará una petición [Rack][] al servidor de la aplicación.)
## Servidor Web
-Si la petición no ha sido ya retornada por el reverse proxy,
-o si no está siendo usado ninguno,
+En el caso que la petición no haya sido retornada por el proxy inverso,
+o si no hay ninguno en uso,
la petición será reenviada a un **servidor web**.
[Mongrel][], [Thin][], [Ebb][], y un número de programas menos conocidos
-se encargan de este rol.
-
-Una vez la respuesta es recibida por el servidor web,
-esta será parseada y enviada al [Rack][] a travez de un manipulador (handler).
+se encargan de cumplir con este rol.
+Una vez que la respuesta sea recibida por el servidor web,
+esta será parseada y enviada al [Rack][] a través de un manipulador.
## Rack y Merb
-Merb recibe la petición como un entorno [Rack][].
-Un entorno Rack envuelve todo las cabeceras de estilo CGI para la petición.
-Debido a que Merb usa Rack como una capa de abstracción,
-cambiar servidores web es realmente fácil.
-Puede que oigas a gente referirse a estos servidores web como adaptadores.
-
-Antes de que Merb despache la petición a travez de la stack,
-uno puede adicionar "middlewares Rack".
-Los middlewares Rack pueden procesar la petición antes de que sea enviada a
-travez Merb.
-Alternativamente, estos pueden "envolver" la petición,
-permitiendo que código arbitrario sea ejecutado lo mismo antes que después de
-que la petición viaje a travez de la stack.
-Los middlewares Rack pueden ser herramientas muy poderosas, permitiéndote
-mantener logs a la medida, cacheo, hacer análisis de rendimiento, etc.
-
-Nosotros no cubriremos extensivamente el uso de Rack aquí,
-pero puedes encontrar la configuración Rack de Merb en el archivo
-``config/rack.rb`` (en la aplicación de stack completa).
-
-## Enrutador (Router)
-
-Una vez la petición ha sido pasada a la stack,
-esta le pregunta al enrutador adonde ir.
-La petición entonces se envía sí misma al controlador.
-
-El trabajo del Enrutador es asignar parámetros extraidos de la petición
-y decirle a la petición adonde ir.
-En la mayoría de los casos, el enrutador mapea una petición a un método
-(acción) de un controlador
-y también asigna parámetros extraidos de la petición.
-
-Entre bastidores la framework Merb ha hecho ya cierto trabajo para tí.
-En el momento que una petición alcanza el controlador, Merb se ha encargado de:
-
-* Extraer la ruta URI de la petición.
-* Parsear cualesquiera datos Post o Query enviados por el cliente,
- metiendolos en el hash ``params``.
+Merb recibe una petición dentro del entorno [Rack][].
+Un entorno Rack envuelve todas las cabeceras de estilo CGI para una petición.
+Debido a que Merb utiliza [Rack][] como una capa de abstracción,
+el cambio de servidores web resulta ser sumamente simple.
+Estos servidores web pueden ser también llamados "adaptadores".
+
+Antes de que Merb despache una petición a través de la stack,
+uno puede adicionar diferentes "middlewares" en el [Rack][].
+Estos pueden procesar la petición antes de que esta sea enviada a través de Merb.
+Alternativamente, también pueden "envolver" una petición,
+permitiendo así la ejecución de código arbitrario tanto antes como después
+del paso de la petición a través de la stack.
+Los [middlewares][] del Rack pueden ser herramientas muy poderosas, permitiéndole
+mantener registros de eventos a medida, cacheo, realizar análisis de rendimiento, etc.
+
+El uso de [Rack][] no será cubierto extensivamente en este capitulo,
+pero usted puede encontrar la configuración del [Rack][] de Merb en el
+archivo ``config/rack.rb`` (en la aplicación de stack).
+
+## Enrutador
+
+Una vez que la petición ha pasado al stack,
+esta le pregunta al enrutador hacia donde debe dirigirse.
+Entonces la petición se envía a sí misma hacia el controlador.
+
+El trabajo del Enrutador es la asignación de parámetros extraídos
+de la petición aunque, ademas, debe direccionar a la misma.
+En la mayoría de los casos, el enrutador conecta una petición a un
+determinado método (acción) definido en un controlador
+asignando aquellos parámetros extraídos de la petición al mismo.
+
+Detrás de escena, la plataforma Merb ya ha realizado cierto trabajo por usted.
+Al momento que una petición alcanza un controlador, Merb se ha encargado de:
+
+* Extraer la ruta [URI][] de la petición.
+* Parsear los datos Post o Query enviados por el cliente,
+ organizándolos en la colección ``params``.
* Configurar el acceso a las cookies de la petición y a la sesión actual.
-El desarrollador puede usar cualquiera de esta información para enrutar la
-petición.
-Por favor mira el capítulo sobre enrutamiento (???) para más información.
+El desarrollador puede usar esta información para enrutar la petición.
+Por favor, referirse al capítulo sobre enrutamiento (???) para más información.
## Acción del Controlador
-La petición ha sido despachada a un método de un controlador.
-Por ejemplo: el/la método/acción ``show`` del controlador ``Articulos``.
-La acción puede mostrar una vista o simplemente retornar una cadena.
-El valor retornado desde el método será usado para construir una respuesta Rack.
-Una respuesta Rack es simplemente una tupla sencilla que contiene
- ``[estado, cabeceras, cuerpo]``.
+La petición es ahora despachada a un determinado método de un controlador.
+Por ejemplo: el método o la acción ``mostrar`` del controlador ``Articulos``.
+La acción puede mostrar una vista o simplemente retornar una cadena de caracteres.
+El valor retornado por el método será usado para generar la respuesta del Rack.
+Esta es simplemente una tupla sencilla que contiene [estado, cabeceras, cuerpo].
## Hacia afuera
-Finalmente Merb envía una respuesta Rack bien construida de regreso al servidor
-web.
-El servidor web a su vez conforma una respuesta HTTP que es enviada por el
-cable.
-El cliente recibe la respuesta y la interpreta para, por ejemplo,
-mostrar una página web.
-
+Finalmente, Merb retorna la respuesta Rack bien construida al servidor web.
+El servidor web, a su vez, confecciona una respuesta HTTP
+que será enviada por el cable.
+El cliente recibe la respuesta y la interpreta, por ejemplo,
+mostrándola como una página web.
## Cacheo
-Si el cacheo está habilitado,
-la petición podría no viajar a travez de todo el proceso anteriormente descrito.
-El Cacheo puede ocurrir dentro Merb, en un Middleware Rack, un servidor Proxy,
+En el caso el cual el cacheo está habilitado,
+la petición podría no viajar a través de todo el proceso anteriormente descrito.
+El Cacheo puede ocurrir dentro Merb, en un middleware del Rack, un servidor Proxy,
o el navegador web cliente.
-
-
[Apache]: http://httpd.apache.org/
[GlassFesh]: /deployment/jrupor
[mod\_proxy]: http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
@@ -138,3 +127,5 @@ o el navegador web cliente.
[Phusion Passenger]: /deployment/passenger
[Rack]: http://rack.rubyforge.org/
[Thin]: http://code.macournoyer.com/thin/
+[middlewares]: ...
+[URI]: ...
diff --git a/book-content/es/2-getting-started/9-router.markdown b/book-content/es/2-getting-started/9-router.markdown
index 7ec787f1..73b516f6 100644
--- a/book-content/es/2-getting-started/9-router.markdown
+++ b/book-content/es/2-getting-started/9-router.markdown
@@ -1 +1,4 @@
-#Router
\ No newline at end of file
+# Enrutador
+
+* Esto será una tabla de contenidos (este texto será pegado).
+{:toc}
\ No newline at end of file
diff --git a/book-content/es/2-getting-started/toc.markdown b/book-content/es/2-getting-started/toc.markdown
index 0b5a90b5..821669c8 100644
--- a/book-content/es/2-getting-started/toc.markdown
+++ b/book-content/es/2-getting-started/toc.markdown
@@ -1,19 +1,78 @@
# getting-started
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
+
\ No newline at end of file