diff --git a/tutorials/Spanish/01 Comenzando/index.html b/tutorials/Spanish/01 Comenzando/index.html index dfb871c7..a7e66b28 100644 --- a/tutorials/Spanish/01 Comenzando/index.html +++ b/tutorials/Spanish/01 Comenzando/index.html @@ -13,34 +13,37 @@
-In this tutorial we're going to cover setting-up a development enviornment with which you can build your Phaser games. This will include running a local web server, picking an IDE, getting the latest version of Phaser and checking it all works together properly.
+En este tutorial vamos a ver cómo configurar un entorno de desarrollo con el que puedas construir tus juegos en Phaser. Esto incluirá el arrancar un servidor web local, escoger un IDE (un programa para gestionar y escribir el código), obtener la última versión de Phaser y comprobar que todo funciona adecuadamente. +
+ +"¿Por qué necesito un servidor web local? ¿No puedo simplemente arrastrar los ficheros html a mi navegador?"
-"Why do I need a local web server? Can't I just drag the html files onto my browser?"
+No, hoy en día, no. Entiendo que pueda ser un poco confuso, incluso contradictorio a veces, pero todo es por cuestión de la seguridad del navegador. Si estás haciendo una web html estática, quizás con algunas imágenes en ella, entonces sí puedes arrastrar felizmente ese fichero a tu navegador y ver el resultado final. También puedes "Guardar como" páginas web enteras y reabrirlas, con todo el contenido prácticamente intacto. Si ambas cosas funcionan, ¿por qué no puedes arrastrar un juego HTML5 en un navegador y ejecutarlo? +
+ +Tiene que ver con el protocolo que se usa para acceder a los archivos. Cuando solicitas algo por internet estás usando http, y el nivel de seguridad del servidor es suficiente para asegurarse de que solo puedes acceder a los ficheros que se supone que debes acceder. Pero cuando arrastras un fichero en un navegador se accede por medio del sistema de ficheros local (técnicamente, el protocolo file://) y esto está muy restringido, por razones obvias. Bajo file:// no hay concepto de dominios, no hay seguridad a nivel de servidor, solo un sistema de ficheros a pelo. Pregúntate esto: ¿de verdad quieres que JavaScript tenga la habilidad de abrir ficheros de todo tu sistema de archivos local? Tu respuesta inmediata por supuesto debería ser: "¡ni de coña!". Si un script en JavaScript tuviera total libertad para trabajar en file:// no habría nada que le impidiese abrir prácticamente cualquier fichero que quisiera y enviarlo sabe Dios dónde.
-Not these days, no. I appreciate that it's a bit confusing, even contradictory at times, but it all boils down to browser security. If you're making a static html web page, perhaps with a few images in it, then you can happily drag this file into your browser and see the end results. You can also "Save As" entire web pages locally and re-open them, with all the contents mostly intact. If both of these things work why can't you drag an HTML5 game into a browser and run it?
+Dado que esto es tan peligroso, los navegadores se blindan más fuerte que Alcatraz cuando se ejecutan en file://. Cada página es tratada como un dominio local único. Por eso "Guardar página web" funciona, hasta cierto punto. Se abre bajo las mismas restricciones cross-site (a través de varios servidores) que si estuvieran en un servidor online. Hay un post más detallado sobre esto en el Chromium blog que bien merece una lectura (en inglés).
-It's to do with the protocol used to access the files. When you request anything over the web you're using http, and the server level security is enough to ensure you can only access files you're meant to. But when you drag a file in it's loaded via the local file system (technically file://) and that is massively restricted, for obvious reasons. Under file:// there's no concept of domains, no server level security, just a raw file system. Ask yourself this: do you really want JavaScript to have the ability to load files from your local file system? Your immediate answer should of course be "not in a million years!". If JavaScript had free reign while operating under file:// there would be nothing stopping it loading pretty much any file it fancied and sending it off who knows where.
+Tu juego va a necesitar cargar recursos. Imágenes, ficheros de audio, datos JSON, quizás más ficheros JavaScript. Para hacer esto necesita que se ejecute libre de los grilletes de la seguridad del navegador. Necesita que http:// acceda a los ficheros del juego. Y para esto necesitamos un servidor web.
-Because this is so dangerous browsers lock themselves down tighter than Alcatraz when running under file://. Every single page becomes treated as a unique local domain. That is why "Save Web page" works, to a degree. It opens under the same cross-site restrictions as if they were on a live server. There's a detailed post about it on the Chromium blog: http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html.
- -Your game is going to need to load in resources. Images, audio files, JSON data, maybe other JavaScript files. In order to do this it needs to run unhindered by the browser security shackles. It needs http:// access to the game files. And for that we need a web server.
- - +