Merge pull request chromaui#24 from luchux/language-spanish

Language spanish - composite components

content/spanish/composite-component.md

@@ -7,23 +7,23 @@ commit: f1d2297
 
 # Ensamblar un componente compuesto
 
-En el último capítulo construimos nuestro primer componente; este capítulo extiende lo que aprendimos para construir TaskList, una lista de Tareas. Combinemos componentes juntos y veamos qué sucede cuando se añade más complejidad.
+En el último capítulo construimos nuestro primer componente; este capítulo extiende lo que aprendimos para construir TaskList, una lista de Tareas. Combinemos componentes en conjunto y veamos qué sucede cuando se añade más complejidad.
 
 ## Lista de Tareas
 
-Taskbox enfatiza las tareas ancladas colocándolas por encima de las tareas predeterminadas. Esto produce dos variaciones de `TaskList` para las que necesita crear historias: ítems por defecto y ítems por defecto y anclados.
+Taskbox enfatiza las tareas ancladas colocándolas por encima de las tareas predeterminadas. Esto produce dos variaciones de `TaskList` para las que necesita crear historias: ítems por defecto e ítems por defecto y anclados.
 
 ![default and pinned tasks](/tasklist-states-1.png)
 
-Dado que los datos de `Tareas` pueden enviarse asincrónicamente, **también** necesitamos un estado de carga para renderizar en ausencia de alguna conexión. Además, también se requiere un estado vacío para cuando no hay tareas.
+Dado que los datos de `Tareas` pueden enviarse asincrónicamente, **también** necesitamos un estado de cargando para renderizar en ausencia de alguna conexión. Además, también se requiere un estado vacío para cuando no hay tareas.
 
 ![empty and loading tasks](/tasklist-states-2.png)
 
 ## Empezar la configuración
 
 Un componente compuesto no es muy diferente de los componentes básicos que contiene. Crea un componente `TaskList` y un archivo de historia que lo acompañe: `src/components/TaskList.js` y `src/components/TaskList.stories.js`.
 
-Comienza con una implementación aproximada de la `TaskList`. Necesitarás importar el componente `Tareas` de antes y pasarle los atributos y acciones como inputs.
+Comienza con una implementación aproximada de la `TaskList`. Necesitarás importar el componente `Tareas` del capítulo anterior y pasarle los atributos y acciones como entrada.
 
 ```javascript
 import React from 'react';
@@ -89,13 +89,13 @@ storiesOf('TaskList', module)
  .add('empty', () => <TaskList tasks={[]} {...actions} />);
 ```
 
-`addDecorator()` nos permite añadir algo de "contexto" a la representación de cada tarea. En este caso añadimos relleno alrededor de la lista para que sea más fácil de verificar visualmente.
+`addDecorator()` nos permite añadir algún "contexto" al renderizado de cada tarea. En este caso añadimos relleno alrededor de la lista para que sea más fácil de verificar visualmente.
 
 <div class="aside">
-Los <a href="https://storybook.js.org/addons/introduction/#1-decorators"><b>Decoradores</b></a> son una forma de proporcionar envoltorios arbitrarios a las historias. En este caso estamos usando un decorador para añadir estilo. También se pueden utilizar para envolver historias en "proveedores", es decir, componentes de la librebría que establecen el contexto de React. 
+Los <a href="https://storybook.js.org/addons/introduction/#1-decorators"><b>Decoradores</b></a> son una forma de proporcionar envoltorios arbitrarios a las historias. En este caso estamos usando un decorador para añadir estilo. También se pueden utilizar para envolver historias en "proveedores", es decir, componentes de la librebría que establecen el contexto de React.
 </div>
 
-`createTask()` es una función de ayuda que genera la forma de una Tarea que creamos y exportamos desde el archivo `Task.stories.js`. De manera similar, las `acciones` exportadas de `Task.stories.js` definieron las acciones (comunmente llamadas mockeadas) que espera un componente `Task`, el cual también necesita la `TaskList`. 
+`createTask()` es una función de ayuda que genera la forma de una Tarea que creamos y exportamos desde el archivo `Task.stories.js`. De manera similar, las `acciones` exportadas de `Task.stories.js` definieron las acciones (comunmente llamadas mockeadas) que espera un componente `Task`, el cual también necesita la `TaskList`.
 
 Ahora revise Storybook para ver las nuevas historias de la lista de tareas.
 
@@ -108,7 +108,7 @@ Ahora revise Storybook para ver las nuevas historias de la lista de tareas.
 
 ## Construir los estados
 
-Nuestro componente sigue siendo muy rudimentario, pero ahora tenemos una idea de las historias en las que trabajar. Podrías estar pensando que el envoltorio de `.list-items` es demasiado simplista. Tienes razón, en la mayoría de los casos no crearíamos un nuevo componente sólo para añadir un envoltorio. Pero la **complejidad real** del componente `TaskList` se revela en los casos `withPinnedTasks`, `loading`, y `empty`.
+Nuestro componente sigue siendo muy rudimentario, pero ahora tenemos una idea de las historias en las que trabajaremos. Podrías estar pensando que el envoltorio de `.list-items` es demasiado simplista. Tienes razón, en la mayoría de los casos no crearíamos un nuevo componente sólo para añadir un envoltorio. Pero la **complejidad real** del componente `TaskList` se revela en los casos extremos `withPinnedTasks`, `loading`, y `empty`.
 
 ```javascript
 import React from 'react';
@@ -170,7 +170,7 @@ function TaskList({ loading, tasks, onPinTask, onArchiveTask }) {
 export default TaskList;
 ```
 
-El marcado añadido da como resultado la siguiente interfaz de usuario:
+El etiquetado añadido da como resultado la siguiente interfaz de usuario:
 
 <video autoPlay muted playsInline loop>
  <source
@@ -183,7 +183,7 @@ Observa la posición del elemento anclado en la lista. Queremos que el elemento
 
 ## Requisitos de data y props
 
-A medida que el componente crece, también lo hacen los inputs requeridos de `TaskList`. Define las props requeridas de `TaskList`. Debido a que `Task` es un componente hijo, asegúrate de proporcionar los datos en la forma correcta para renderizarlos. Para ahorrar tiempo y dolores de cabeza, reutiliza los propTypes que definiste en `Tareas` anteriormente.
+A medida que el componente crece, también lo hacen los parámetros de entrada requeridos de `TaskList`. Define las props requeridas de `TaskList`. Debido a que `Task` es un componente hijo, asegúrate de proporcionar los datos en la forma correcta para renderizarlo. Para ahorrar tiempo y dolores de cabeza, reutiliza los propTypes que definiste en `Tareas` anteriormente.
 
 ```javascript
 import React from 'react';
@@ -210,7 +210,7 @@ export default TaskList;
 
 ## Pruebas automatizadas
 
-En el capítulo anterior aprendimos a capturar historias de prueba utilizando Storyshots. Con el componente `Task` no había mucha complejidad para probar más allá de que se mostrara correctamente. Dado que `TaskList` añade otra capa de complejidad, queremos verificar que ciertas entradas produzcan ciertas salidas de una manera adecuada con pruebas automáticas. Para hacer esto crearemos test unitarios utilizando [Jest](https://facebook.github.io/jest/) junto con un renderizador de prueba como [Enzyme](http:https://airbnb.io/enzyme/).
+En el capítulo anterior aprendimos a capturar historias de prueba utilizando Storyshots. Con el componente `Task` no había mucha complejidad para probar más allá de que se renderice correctamente. Dado que `TaskList` añade otra capa de complejidad, queremos verificar que ciertas entradas produzcan ciertas salidas de una manera adecuada con pruebas automáticas. Para hacer esto crearemos test unitarios utilizando [Jest](https://facebook.github.io/jest/) junto con un renderizador de prueba como [Enzyme](http:https://airbnb.io/enzyme/).
 
 ![Jest logo](/logo-jest.png)
 
@@ -220,7 +220,7 @@ Las historias de Storybook combinadas con pruebas visuales manuales y pruebas de
 
 Sin embargo, a veces el diablo está en los detalles. Se necesita un framework de pruebas que sea explícito sobre esos detalles. Lo que nos lleva a hacer pruebas unitarias.
 
-En nuestro caso, queremos que nuestra `TaskList` muestre cualquier tarea anclada **antes de** las tareas no ancladas que sea pasada en la prop `tasks`. Aunque tenemos una historia (`withPinnedTasks`) para probar este escenario exacto; puede ser ambiguo para un revisor humano que si el componente **stop** ordena las tareas de esta manera, es un error. Ciertamente no gritará **"¡Mal!"** para el ojo casual.
+En nuestro caso, queremos que nuestra `TaskList` muestre cualquier tarea anclada **antes de** las tareas no ancladas que sean pasadas en la prop `tasks`. Aunque tenemos una historia (`withPinnedTasks`) para probar este escenario exacto; puede ser ambiguo para un revisor humano que si el componente **no** ordena las tareas de esta manera, es un error. Ciertamente no gritará **"¡Mal!"** para el ojo casual.
 
 Por lo tanto, para evitar este problema, podemos usar Jest para renderizar la historia en el DOM y ejecutar algún código de consulta del DOM para verificar las características salientes de la salida.
 
@@ -247,6 +247,6 @@ it('renders pinned tasks at the start of the list', () => {
 
 ![TaskList test runner](/tasklist-testrunner.png)
 
-Nota que hemos sido capaces de reutilizar la lista de tareas `withPinnedTasks' tanto en la prueba de la historia como en el test unitario; de esta manera podemos continuar aprovechando un recurso existente (los ejemplos que representan configuraciones interesantes de un componente) de más y más maneras.
+Nota que hemos sido capaces de reutilizar la lista de tareas `withPinnedTasks` tanto en la prueba de la historia como en el test unitario; de esta manera podemos continuar aprovechando un recurso existente (los ejemplos que representan configuraciones interesantes de un componente) de más y más maneras.
 
-Note también que esta prueba es bastante frágil. Es posible que a medida que el proyecto madure y que la implementación exacta de la `Tarea` cambie --quizás usando un nombre de clase diferente o un "área de texto" en lugar de un "input"-- la prueba falle y necesite ser actualizada. Esto no es necesariamente un problema, sino más bien una indicación de ser bastante cuidadoso usando pruebas unitarias para la UI. No son fáciles de mantener. En su lugar, confía en las pruebas visuales, de instantáneas y de regresión visual (mira el [capitulo sobre las pruebas](/test/)) siempre que te sea posible.
+Note también que esta prueba es bastante frágil. Es posible que a medida que el proyecto madure y que la implementación exacta de la `Tarea` cambie --quizás usando un nombre de clase diferente o un "área de texto" en lugar de un "input" en el etiquetado-- la prueba falle y necesite ser actualizada. Esto no es necesariamente un problema, sino más bien una indicación de ser bastante cuidadoso usando pruebas unitarias para la UI. No son fáciles de mantener. En su lugar, confía en las pruebas visuales, de instantáneas y de regresión visual (mira el [capitulo sobre las pruebas](/test/)) siempre que te sea posible.

content/spanish/data.md

@@ -1,23 +1,23 @@
 ---
-title: "Wire in data"
-tocTitle: "Data"
-description: "Learn how to wire in data to your UI component"
+title: "Introducir datos"
+tocTitle: "Datos"
+description: "Aprende como introducir datos a tus componentes UI"
 commit: ea58e96
 ---
 
-# Wire in data
+# Introducir datos
 
-So far we created isolated stateless components –great for Storybook, but ultimately not useful until we give them some data in our app.
+Hasta ahora hemos creado componentes aislados sin estado, muy útiles para Storybook, pero finalmente no son útiles hasta que les proporcionemos algunos datos en nuestra aplicación.
 
-This tutorial doesn’t focus on the particulars of building an app so we won’t dig into those details here. But we will take a moment to look at a common pattern for wiring in data with container components.
+Este tutorial no se centra en los detalles de la construcción de una aplicación, por lo que no profundizaremos en esos detalles aquí. Pero nos tomaremos un momento para observar un patrón común para introducir datos con componentes contenedores.
 
-## Container components
+## Componentes contenedores
 
-Our `TaskList` component as currently written is “presentational” (see [this blog post](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)) in that it doesn’t talk to anything external to its own implementation. To get data into it, we need a “container”.
+Nuestro componente `TaskList` como lo hemos escrito es de “presentación” (ver [artículo en blog](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)) en el sentido que no se comunica con nada externo a su implementación. Para pasarle datos, necesitamos un "contenedor".
 
-This example uses [Redux](https://redux.js.org/), the most popular React library for storing data, to build a simple data model for our app. However, the pattern used here applies just as well to other data management libraries like [Apollo](https://www.apollographql.com/client/) and [MobX](https://mobx.js.org/).
+Este ejemplo utiliza [Redux](https://redux.js.org/), la librería mas popular de React para almacenar datos, que nos permite crear un modelo simple de datos para la aplicación. De todos modos, el patrón que utilizaremos también se aplica a otras librerías de manejo de datos como [Apollo](https://www.apollographql.com/client/) y [MobX](https://mobx.js.org/).
 
-First we’ll construct a simple Redux store that responds to actions that change the state of tasks, in a file called `lib/redux.js` (intentionally kept simple):
+Primero construiremos un simple store Redux que responde a acciones que cambian el estado de una tarea, en un archivo llamado `lib/redux.js` (intencionalmente lo mantenemos simple):
 
 ```javascript
 // A simple redux store/actions/reducer implementation.
@@ -71,7 +71,7 @@ const defaultTasks = [
 export default createStore(reducer, { tasks: defaultTasks });
 ```
 
-Then we’ll update the default export from the `TaskList` component to connect to the Redux store and render the tasks we are interested in
+Luego actualizaremos lo exportado por defecto en el componente `TaskList` para conectarlo al Store de Redux y renderizar las tareas en las que estamos interesados
 
 ```javascript
 import React from 'react';
@@ -107,9 +107,10 @@ export default connect(
 )(PureTaskList);
 ```
 
-At this stage our Storybook tests will have stopped working, as the `TaskList` is now a container, and no longer expects any props, instead it connects to the store and sets the props on the `PureTaskList` component it wraps.
+En esta etapa, nuestras pruebas de Storybook habrán dejado de funcionar, ya que la `TaskList` ahora es un contenedor y ya no espera ningún props pasado como parámetro, sino que se conecta a la store y establece los props en el componente `PureTaskList` que envuelve.
+
+Sin embargo, podemos resolver este problema fácilmente renderizando `PureTaskList` --el componente de presentación-- en nuestras historias de Storybook:
 
-However, we can easily solve this problem by simply rendering the `PureTaskList` --the presentational component-- in our Storybook stories:
 
 ```javascript
 import React from 'react';

content/spanish/get-started.md

@@ -1,7 +1,7 @@
 ---
-title: "Get started"
-tocTitle: "Get started"
-description: "Setup React Storybook in your development environment"
+title: "Empezando"
+tocTitle: "Empezando"
+description: "Configurar React Storybook en tu entorno de desarrollo"
 commit: 30939d5
 ---