[gnome-devel-docs] Updated Spanish translation

[Daniel Mustieles GarcÃa <dmustieles src gnome org>]

commit fbf94f19ad5eca0cddd2de2742739986ad53216c
Author: Daniel Mustieles <daniel mustieles gmail com>
Date:   Mon Sep 17 14:22:05 2012 +0200

    Updated Spanish translation

 optimization-guide/es/es.po |  116 +------------------------------------------
 1 files changed, 2 insertions(+), 114 deletions(-)
---
diff --git a/optimization-guide/es/es.po b/optimization-guide/es/es.po
index d09b84e..d9a74d6 100644
--- a/optimization-guide/es/es.po
+++ b/optimization-guide/es/es.po
@@ -9,10 +9,11 @@ msgid ""
 msgstr ""
 "Project-Id-Version: gnome-devel-docs.optimization-guide.master\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2012-02-10 19:19+0000\n"
+"POT-Creation-Date: 2012-08-18 22:25+0000\n"
 "PO-Revision-Date: 2012-02-12 20:34+0100\n"
 "Last-Translator: Daniel Mustieles <daniel mustieles gmail com>\n"
 "Language-Team: EspaÃol <gnome-es-list gnome org>\n"
+"Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
@@ -467,11 +468,6 @@ msgstr ""
 "en software de GNOME"
 
 #: C/optimization-massif.xml:5(para)
-#| msgid ""
-#| "This article describes how to use the <application>Massif</application> "
-#| "heap profiler with GNOME applications. We describe how to invoke, "
-#| "interpret, and act on the output of <application>Massif</application>. "
-#| "The <application>Same GNOME</application> game is used as an example."
 msgid ""
 "This article describes how to use the <application>Massif</application> heap "
 "profiler with GNOME applications. We describe how to invoke, interpret, and "
@@ -581,11 +577,6 @@ msgstr "Su lÃnea de comando deberÃa parecerse a esta:"
 
 #: C/optimization-massif.xml:32(programlisting)
 #, no-wrap
-#| msgid ""
-#| "\n"
-#| "valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \\\n"
-#| "         --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc same-gnome\n"
-#| "        "
 msgid ""
 "\n"
 "valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \\\n"
@@ -598,10 +589,6 @@ msgstr ""
 "        "
 
 #: C/optimization-massif.xml:36(para)
-#| msgid ""
-#| "<application>Same GNOME</application> is the program we will be using as "
-#| "an example. Be warned that, since valgrind emulates the CPU, it will run "
-#| "<emphasis>very</emphasis> slowly. You will also need a lot of memory."
 msgid ""
 "<application>Swell Foop</application> is the program we will be using as an "
 "example. Be warned that, since valgrind emulates the CPU, it will run "
@@ -644,9 +631,6 @@ msgstr ""
 "Para ilustrar esto se usarà la salida del comando anterior."
 
 #: C/optimization-massif.xml:49(title)
-#| msgid ""
-#| "<application>Massif</application> output for the unoptimized version of "
-#| "the <application>Same GNOME</application> program."
 msgid ""
 "<application>Massif</application> output for the unoptimized version of the "
 "<application>Swell Foop</application> program."
@@ -655,19 +639,6 @@ msgstr ""
 "del programa <application>Swell Foop</application>."
 
 #: C/optimization-massif.xml:56(para)
-#| msgid ""
-#| "<xref linkend=\"optimization-massif-FIG-output-unoptimized\"/> shows a "
-#| "typical postscript output from <application>Massif</application>. This is "
-#| "the result you would get from playing a single game of <application>Same "
-#| "GNOME</application> (version 2.8.0) and then quitting. The postscript "
-#| "file will have a name like <filename>massif.12345.ps</filename> and the "
-#| "text file will be called <filename>massif.12345.txt</filename>. The "
-#| "number in the middle is the process ID of the program that was examined. "
-#| "If you actually try this example you will find two versions of each file, "
-#| "with slightly different numbers, this is because <application>Same GNOME</"
-#| "application> starts a second process and <application>Massif</"
-#| "application> follows that too. We will ignore this second process, it "
-#| "consumes very little memory."
 msgid ""
 "<xref linkend=\"optimization-massif-FIG-output-unoptimized\"/> shows a "
 "typical postscript output from <application>Massif</application>. This is "
@@ -708,22 +679,6 @@ msgstr ""
 
 #: C/optimization-massif.xml:62(programlisting)
 #, no-wrap
-#| msgid ""
-#| "\n"
-#| "Command: ./same-gnome \n"
-#| "\n"
-#| "== 0 ===========================\n"
-#| "Heap allocation functions accounted for 90.4% of measured spacetime\n"
-#| "\n"
-#| "Called from:\n"
-#| "  28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
-#| "\n"
-#| "    6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
-#| "\n"
-#| "    5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)\n"
-#| "\n"
-#| "    3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)\n"
-#| "        "
 msgid ""
 "\n"
 "Command: ./swell-foop\n"
@@ -778,22 +733,6 @@ msgstr ""
 
 #: C/optimization-massif.xml:80(programlisting)
 #, no-wrap
-#| msgid ""
-#| "\n"
-#| "== 4 ===========================\n"
-#| "Context accounted for 28.8% of measured spacetime\n"
-#| "  0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
-#| "  0x3A998998: (within /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)\n"
-#| "  0x6C2760: (within /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
-#| "  0x6C285E: gdk_pixbuf_new_from_file (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
-#| "\n"
-#| "Called from:\n"
-#| "  27.8% : 0x804C1A3: load_scenario (same-gnome.c:463)\n"
-#| "\n"
-#| "    0.9% : 0x3E8095E: (within /usr/lib/libgnomeui-2.so.0.792.0)\n"
-#| "\n"
-#| "  and 1 other insignificant place\n"
-#| "        "
 msgid ""
 "\n"
 "== 4 ===========================\n"
@@ -828,15 +767,6 @@ msgstr ""
 "        "
 
 #: C/optimization-massif.xml:95(para)
-#| msgid ""
-#| "The first line tells us we are now four levels deep into the stack. Below "
-#| "it is a listing of the function calls that leads from here to "
-#| "gdk_pixbuf_new. Finally there is a list of functions that are at the next "
-#| "level down and call these functions. There are, of course, also entries "
-#| "for levels 1, 2, and 3, but this is the first level to reach right down "
-#| "through the GDK code to the <application>Same GNOME</application> code. "
-#| "From this listing, we can see instantly that the problem code is "
-#| "load_scenario."
 msgid ""
 "The first line tells us we are now four levels deep into the stack. Below it "
 "is a listing of the function calls that leads from here to gdk_pixbuf_new. "
@@ -899,16 +829,6 @@ msgstr ""
 "Por ello es mejor reducir la cantidad de memoria reservada."
 
 #: C/optimization-massif.xml:107(para)
-#| msgid ""
-#| "Unfortunately, the choice of optimization is also constrained by the "
-#| "needs of the program. The size of the pixbuf data in <application>Same "
-#| "GNOME</application> is determined by the size of the game's graphics and "
-#| "cannot be easily reduced. However, the amount of time it spends loaded "
-#| "into memory can be drastically reduced. <xref linkend=\"optimization-"
-#| "massif-FIG-output-optimized\"/> shows the <application>Massif</"
-#| "application> analysis of <application>Same GNOME</application> after "
-#| "being altered to dispose of the pixbufs once the images have been loaded "
-#| "into the X server."
 msgid ""
 "Unfortunately, the choice of optimization is also constrained by the needs "
 "of the program. The size of the pixbuf data in <application>Swell Foop</"
@@ -930,9 +850,6 @@ msgstr ""
 "los pixbuf una vez que se han cargado las imÃgenes en el servidor X."
 
 #: C/optimization-massif.xml:111(title)
-#| msgid ""
-#| "<application>Massif</application> output for the optimized "
-#| "<application>Same GNOME</application> program."
 msgid ""
 "<application>Massif</application> output for the optimized "
 "<application>Swell Foop</application> program."
@@ -968,22 +885,6 @@ msgstr ""
 
 #: C/optimization-massif.xml:124(programlisting)
 #, no-wrap
-#| msgid ""
-#| "\n"
-#| "Command: ./same-gnome \n"
-#| "\n"
-#| "== 0 ===========================\n"
-#| "Heap allocation functions accounted for 87.6% of measured spacetime\n"
-#| "\n"
-#| "Called from:\n"
-#| "    7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
-#| "\n"
-#| "    7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)\n"
-#| "\n"
-#| "    6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)\n"
-#| "\n"
-#| "    5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)\n"
-#| "        "
 msgid ""
 "\n"
 "Command: ./swell-foop\n"
@@ -1095,19 +996,6 @@ msgstr ""
 "bueno para ello."
 
 #: C/optimization-massif.xml:167(para)
-#| msgid ""
-#| "Secondly, <application>Massif</application> only takes into account the "
-#| "memory used by your own program. Resources like pixmaps are stored in the "
-#| "X server and aren't considered by <application>Massif</application>. In "
-#| "the <application>Same GNOME</application> example we have actually only "
-#| "moved the memory consumption from client-side pixbufs to server-side "
-#| "pixmaps. Even though we cheated there are performance gains. Keeping the "
-#| "image data in the X server makes the graphics routines quicker and "
-#| "removes a lot of inter-process communication. Also, the pixmaps will be "
-#| "stored in a native graphics format which is often more compact than the "
-#| "32-bit RGBA format used by gdk_pixbuf. To measure the effect of pixmaps, "
-#| "and other X resources use the <ulink type=\"http\" url=\"http://www.";
-#| "freedesktop.org/Software/xrestop\">xrestop</ulink> program."
 msgid ""
 "Secondly, <application>Massif</application> only takes into account the "
 "memory used by your own program. Resources like pixmaps are stored in the X "