Add/Update (Translation/ES) sql-versioning (#783)

2 files changed, 109 insertions, 18 deletions

diff --git a/docs/es/sql-versioning.md b/docs/es/sql-versioning.md
new file mode 100644
index 0000000..d836697
--- /dev/null
+++ b/docs/es/sql-versioning.md
@@ -0,0 +1,80 @@
+---
+redirect_from: "/SQL-Versioning"
+---
+
+# Control de versiones SQL
+
+Tenemos dos tipos de versiones:
+
+- Versionado cronológico, Para los archivos sql aceptados
+- Versionado por id, principalmente utilizado para sql pendientes
+
+## Versionado cronológico
+
+Utilizamos el viejo método `MaNGOS` para asegurarnos de que todos los archivos **/data/sql/updates/** se importan en el orden correcto, evitando la doble importación o la omisión de archivos. Para ello, utilizamos una **convención específica para los nombres de los archivos** y añadimos una **cabecera SQL** especial al principio de su contenido.
+
+### Nombres de archivos
+
+El nombre del archivo no debe ser renombrado y debe mantenerse como el nombre que `create_sql.sh` ha creado para el archivo.
+
+El nombre del archivo tendrá este aspecto: `rev_XXXXXXXXXXXXXXXXXXX`
+
+### Cabecera SQL
+
+La cabecera SQL es una consulta especial que **debe** añadirse al principio del contenido de **cada** archivo de actualización sql.
+
+El formato es el siguiente:
+
+```sql
+ALTER TABLE version_db_[database] CHANGE COLUMN [previous_file_name] [this_file_name] bit;
+```
+
+Sustituyendo:
+
+- **[database]** con **world**, **character** o **auth**
+- **[previous_file_name]** con el nombre del último archivo (sin extensión)
+- **[this_file_name]** con el nombre del nuevo archivo en sí (sin extensión)
+
+El siguiente es un ejemplo de la consulta del encabezado SQL (para la base de datos `auth`):
+
+```sql
+ALTER TABLE `version_db_auth` CHANGE COLUMN 2016_07_09_01 2016_07_10_00 bit;
+```
+
+## Control de versiones por ID
+
+Los archivos sql pendientes no pueden utilizar el sistema de protección descrito anteriormente porque no podemos saber previamente la fecha en que serán aceptados. Así que estamos usando un versionado opcional (pero recomendado para los devs y especialmente para los pull requests).
+
+Hemos introducido un campo dentro de las tablas `version_db_*` que es una cadena de clave primaria, y también un campo `required_rev` que se puede utilizar para permitir la relación por versiones.
+
+Por ejemplo, puede crear una versión "X" que esté relacionada con una versión "Y" que no sea necesariamente la anterior.
+
+actualmente utilizamos este comando bash para evitar, en la medida de lo posible, las colisiones entre revisiones:
+
+```bash
+date +%s%N
+```
+
+si se produce una colisión (extremadamente difícil), se puede resolver fácilmente de forma manual sin embargo.
+
+La consulta final será:
+
+```sql
+INSERT INTO `version_db_auth` (`sql_rev`, `required_rev`) VALUES ('1472557015805232200','1472557004102672900');
+```
+
+o en caso de que no se requiera: `required_rev`:
+
+```sql
+INSERT INTO `version_db_auth` (`sql_rev`) VALUES ('1472557015805232200');
+```
+
+Añadiéndolo en la primera línea de su sql, genera un error en caso de doble importación; como por ejemplo para el versionado cronológico.
+
+Hay un script bash en las carpetas pending_* que creará un sql con esta fila en la primera línea para usted, además nombrará el archivo que será reconocido por nuestro sistema de importación. Le sugerimos que lo utilice.
+
+## El sistema de importación pendiente
+
+Como se ha dicho antes, tenemos un flujo de trabajo especial para PR para permitir la consistencia de los datos de la base de datos para los desarrolladores. Requiere que se hagan algunas cosas en el sql de su RP para que sea compatible con nuestro sistema de importación y le permita evitar la doble importación de las mismas consultas.
+
+La forma de hacerlo se describe en el artículo [Cómo crear un pull request](How-to-create-a-PR)
diff --git a/docs/sql-versioning.md b/docs/sql-versioning.md
index 18d60c7..beaa4ad 100644
--- a/docs/sql-versioning.md
+++ b/docs/sql-versioning.md
@@ -7,7 +7,6 @@ redirect_from: "/SQL-Versioning"
 We've two kind of versions:
 
 - Chronological versioning, For accepted sql files
-
 - Versioning by id, mostly used for pending sql
 
 ## Chronological Versioning
@@ -18,10 +17,9 @@ In order to achieve this, we use a specific **convention for file names** and we
 
 ### File names
 
-The file name should not be renamed and should be kept as the name `creat_sql.sh` has created for the file.
+The file name should not be renamed and should be kept as the name `create_sql.sh` has created for the file.
 
-The file name will look like this:
-`rev_XXXXXXXXXXXXXXXXXXX`
+The file name will look like this: `rev_XXXXXXXXXXXXXXXXXXX`
 
 ### SQL Header
 
@@ -29,20 +27,25 @@ The SQL Header is a special query that **must** be added at the top of the conte
 
 The format is the following:
 
-ALTER TABLE version_db_**database** CHANGE COLUMN  **previous_file_name**  **this_file_name**  bit;
+```sql
+ALTER TABLE version_db_[database] CHANGE COLUMN [previous_file_name] [this_file_name] bit;
+```
 
 Replacing:
-- *database* with **world**, **character** or **auth**
-- *previous-file-name* with the name of the latest file ( without extension )
-- *this-file-name** with the name of the new file itself ( without extension )
+
+- **[database]** with **world**, **character** or **auth**
+- **[previous_file_name]** with the name of the latest file (without extension)
+- **[this_file_name]** with the name of the new file itself (without extension)
 
 The following is an example of the SQL Header query ( for auth database ):
 
-`ALTER TABLE version_db_auth CHANGE COLUMN 2016_07_09_01 2016_07_10_00 bit;`
+```sql
+ALTER TABLE `version_db_auth` CHANGE COLUMN 2016_07_09_01 2016_07_10_00 bit;
+```
 
 ## Versioning by id
 
-Pending sql files cannot use the protection system described above because we are not able to know previously the date when they will be accepted. 
+Pending sql files cannot use the protection system described above because we are not able to know previously the date when they will be accepted.
 
 So we're using an optional versioning ( but recommended for devs and expecially for pull requests ).
 
@@ -50,17 +53,25 @@ We've  introduced a field inside version_db_* tables that is a primary key strin
 
 For example you can create a version "X" that is related to a version "Y" that is not necessary the previous one.
 
-currently we're using this bash command to avoid, as much as possibile, collisions between revisions: date +%s%N
+Currently we're using this bash command to avoid, as much as possibile, collisions between revisions:
+
+```bash
+date +%s%N
+```
 
-if a collision happens ( extremely hard ), it can be easily solved manually however.
+If a collision happens ( extremely hard ), it can be easily solved manually however.
 
-the final query will be:
+The final query will be:
 
-`INSERT INTO version_db_auth(sql_rev,required_rev) VALUES ('1472557015805232200','1472557004102672900');`
+```sql
+INSERT INTO `version_db_auth` (`sql_rev`, `required_rev`) VALUES ('1472557015805232200','1472557004102672900');
+```
 
-or in case of not required_rev:
+Or in case of not required_rev:
 
-`INSERT INTO version_db_auth(sql_rev) VALUES ('1472557015805232200');`
+```sql
+INSERT INTO `version_db_auth` (`sql_rev`) VALUES ('1472557015805232200');
+```
 
 Adding it in first line of your sql, it generates an error in case of double import; Such as for chronological versioning.
 
@@ -70,6 +81,6 @@ There's a bash script under pending_* folders that will create an sql with this
 
 As said before, we've a special workflow for PR to allow db data consistency for devs
 
-it requires some stuffs to be done on your PR's sql to be compatible with our import system and allow you to avoid double importing of same queries.
+It requires some stuffs to be done on your PR's sql to be compatible with our import system and allow you to avoid double importing of same queries.
 
-The how to is described under [How to create a PR](How-to-create-a-PR) article
\ No newline at end of file
+The how to is described under [How to create a PR](How-to-create-a-PR) article