De esta forma si elijo el idioma "inglés", se carga el fichero "eng.php" que contiene un array con todas las palabras del interface en ese idioma, luego en la plantilla llamo al elemento del array correspondiente por su clave.
Este sistema está bien, pero recientemente me he cambiado a otro más efectivo y estándar: Los ficheros generados por POedit. Es el sistema que usa Wordpress y muchos otros CMS / Frameworks.

Lo primero es hacerse con el POEdit: http://www.poedit.net/ e instalarlo.
Ahora vamos a nuestra página multi idioma, y editamos todos los ficheros donde aparezcan cadenas de texto que van en múltiples idiomas.
Por ejemplo, encontramos en nuestro formulario de contacto algo como:

Nombre y apellidos:

Esto lo cambiamos por:

:

Efectivamente, toda cadena o conjunto de ellas que sean para traducir, las metemos en esta notación de PHP: _(), que es lo mismo que poner gettext(), vamos que si nos gusta más ponemos:

:

Una vez lo tenemos todo hecho, creamos un nuevo proyecto en POEdit: Archivo -> Nuevo catálogo.
Aquí especificamos varias cosas: En "Información del proyecto" rellenamos los datos. En "carpetas", escribimos en "directorio raíz" el path local raiz del proyecto de nuestra web, por ejemplo (en mac): "/Users/Enrique/Desktop/trabajos/nuevaweb/"
A continuación, debemos decir dentro de ese raíz, donde están las carpetas con los ficheros a ser traducidos. Para ello pinchamos en el botón "Nuevo" (el 2º icono) y ahí metemos las rutas a las carpetas, por ejemplo (en mac): "/Users/Enrique/Desktop/trabajos/nuevaweb/website".
En "Palabras Clave", lo dejamos como está porque por defecto ya trae el "_" o el "gettext" que hemos usado.
Le damos a Aceptar y ya tenemos el proyecto creado. Ahora pinchamos en "Actualizar", y POEdit escaneará las carpetas que hemos especificado buscando los "_()" o "gettext()".
Una vez termine, nos mostrará todas las palabras que ha encontrado. Ahora prodecemos a traducir una por una.
Una vez hemos terminado, le damos a "Guardar", y POEdit crea dos ficheros: "default.mo" (fichero compilado) y "default.po" (fichero editable).
El "mo" lo subimos a: "nuevaweb/website/locale/es_ES/LC_MESSAGES/" donde "es_ES" sería la cadena del idioma que corresponda. La carpeta "website" sería la raiz de la web en sí, donde estaría el "index.php".
Cada vez que pongamos nuevas cadenas o modifiquemos cadenas existentes en nuestra web, hay que volver a generar los "po" y "mo" y subir el "mo". Para ello abrimos el fichero "po" con el POEdit, escaneamos, el programa encuentra todas las palabras nuevas o modificadas, escribimos las nuevas traducciones, guardamos, y subimos el "mo" generado.

Ahora para que nuestra web en PHP cargue esos idiomas, debemos hacer lo siguiente:
Al inicio de cada script PHP, con un include o con la fórmula que se quiera, obtendremos el idioma escogido. El idioma lo debemos tener en este formato: "es_ES".
Entonces ponemos el siguiente código:

$locale="es_ES";
putenv("LC_ALL=$locale");
setlocale(LC_ALL, $locale);
bindtextdomain("default", "./locale");
textdomain("default");
Y ya está, en principio. Digo en principio, porque tenemos un problema: El caché del servidor.

El problema del caché

Nuestro fichero "mo" se queda en la memoria del servidor, esto está muy bien porque hace que las traducciones sean rapidísimas, pero nos crea un gran problema: si modificamos un fichero de idiomas y lo subimos, no veamos los cambios inmediatamente, puesto que el antiguo está "cacheado" en la memoria. Una solución es resetear el Apache, pero esto no lo podemos hacer la mayoría de las veces. Para solucionarlo, usamos este codigo en vez del anterior:

function translation($lang) {
  $rname="default";
  if (GETTEXT_CACHING == 0) {
       $targetFolder = "locale/".$lang."/LC_MESSAGES/";
       $folder = opendir($targetFolder);
       while (false !== ($file = readdir($folder))) {
            $pathFiles = $targetFolder."/".$file;
            if ($file != ".." AND $file != "." AND !is_dir($file) AND strrchr($file,'.') == '.mo' AND $file != $rname.'.mo') {
              unlink($pathFiles);
            }
        }
        closedir($folder);
        $translatefile = $rname.time();
        copy('locale/'.$lang.'/LC_MESSAGES/'.$rname.'.mo','locale/'.$lang.'/LC_MESSAGES/'.$translatefile.'.mo');
        } else $translatefile = $rname;
      
        setlocale(LC_ALL, $lang);
        putenv("LC_ALL=".$lang);
        bindtextdomain($translatefile,'./locale');
        bind_textdomain_codeset($translatefile, 'utf8'); 
        textdomain($translatefile);
}

translation($locale);

Lo que hace es duplicar el fichero "mo" con otro nombre y usar ese nuevo fichero, con esto siempre usaremos una versión nueva no cacheada.
Hay que darle permisos de escritura a la carpeta "LC_MESSAGES". Evidentemente esto lo mantendremos solo en tiempo de desarrollo, una vez la web sea definitiva, el cache ya no nos importará y usaremos el primer código de 5 líneas.

• Persona que tiene una buena idea y quiere iniciar un negocio online desde cero, sin tener tienda física
• Tienda física que quiere tener tienda online
• Persona que ya tiene una tienda online pero la quiere renovar porque se ha quedado anticuada o bien piensa que está pagando al mes una cantidad demasiado elevada a un "hosting especializado en tiendas online".

Aunque yo lo simplificaría más: Personas con conocimientos informáticos a nivel de usuario y personas que no los tienen. Si una persona no tiene conocimientos informáticos a nivel de usuario, o bien no tiene tiempo para ocuparse de la tienda online, entonces tendrá que ponerse en manos de una empresa especializada en tiendas online. A mi este tipo de empresas me da bastante reparo, porque suelen ser bastante caras en relación con lo que ofrecen, sin contar que muchas de estas empresas ofrecen soluciones obsoletas, pero como los clientes no saben de informática, nadie se les va a quejar. Además cuando un cliente se da cuenta de lo que le están haciendo, y se quiere salir, ponen toda clase de trabas para que el cliente se pueda llevar sus datos a otra parte.

Como programador, las tiendas online las dividiría en las que pueden despacharse con un CMS y las que hay que realizar con programación a medida. ¿Cuando debo utilizar una solución u otra? Siempre debemos partir del esquema de tienda que requiere el cliente.

CMS

Los CMS de tienda tipo Prestashop, Magento, etc… se utilizan en estos casos:

• El cliente no tiene web existente, y su esquema de tienda es de lo más típico: categorías, productos, ofertas, outlet, etc… por lo tanto un CMS se le ajusta perfectamente.
• El cliente ya tiene otro CMS y le quiere integrar tienda, en este caso si tiene un Wordpress, se le pone un Jigoshop, etc..
• En el esquema de tienda del cliente hay algunas cosas que no se pueden resolver con un CMS, pero se puede desarrollar / modificar un plugin existente para ese CMS y resolver el problema.
• Al cliente le parece bien el diseño tipico de los CMS de tienda: Portada-Listado-Ficha etc.. con la maquetación Cabecera-columnas-pie.

La ventaja de los CMS es que inicialmente y con pocas horas de desarrollo ponemos la tienda a funcionar, El problema puede venir después, si el cliente, una vez está la tienda funcionando, quiere meter nuevas características a la tienda que no son fácilmente realizables con un CMS.

Programación a medida

Por mucho que les pese a los fans de los CMS, hay muchos casos, donde es imposible utilizar un CMS para darle al cliente todas las características que él quiere. Por eso es tan importante que el cliente haga un esquema de la tienda que requiere, antes de ponerse en contacto con ninguna empresa / freelance para su desarrollo. Casos donde se requiere una programación a medida:

• El cliente quiere un diseño que se aparte del típico de las tiendas mencionado antes.
• Se necesitan características que son de dificil resolución en un CMS, por ejemplo un probador virtual de productos, un customizador de características a medida, reglas complejas de tarificación / envío, etc..
• El propio esquema de la tienda no es el típico carrito-checkout-pasarela.
• Se necesita integrar la tienda con el software de gestión de la tienda física, y este software es del paleolítico (lo más común).

En definitiva, cualquier esquema que se aparte del típico usado por los CMS.

El problema de la programación a medida es precisamente ese, que es "a medida", por lo tanto será más caro y habrá que delimitar todo lo que se quiere hacer de manera precisa.
No vale decir "quiero todo lo que trae el Magento", porque eso te va a salir por un ojo de la cara. En una programación a medida, vas a tener exactamente lo que requieres, en cuanto a diseño y programación, y si luego quieres "estadísticas como las del Prestashop" o cualquier añadido, lo tendrás que pagar.

Evidentemente la ventaja es que tendrás un producto completamente a tu medida, y le podrás poner cualquier característica que se te ocurra.

En resumen, para hacer una tienda online lo primero es escribir en un documento todo lo que va a tener la tienda, y luego informarse informarse informarse, no quedarte con lo que te diga la primera empresa / freelance con la que contactes, pedir valoraciones económicas, e intentar huir siempre que sea posible de las "empresas especializadas en tiendas online que te lo dan todo hecho", porque la final probablemente estarás pagando una pasta mensual por la solución de tienda genérica que te dan ellos, no la que querías tu.

Adobe Wallaby

El problema es que es muy limitada, al menos en esta fase beta. Solo permite hacer animación muy básica: No permite alfas, botones, actionscript (bueno, el stop() sí funciona) y muchas cosas más, por lo que por ahora vale para muy poco.

Google Swiffy

Esta herramienta de Google es toda una sorpresa, partiendo del "swf" (ha de ser generado con compatibilidad Flash Player 8 - Actionscript 2) genera HTML5 con bastantes posibilidades. Al contrario que el Wallaby, sí permite botones, alfas, actionscript básico y bastantes cosas más.
El swf es convertido en 2 ficheros, un html y un runtime.js.
Swiffy crea una representación en JSON de la animación, que es interpretada mediante Javascript.
Todas las pruebas que he hecho han ido bien, se ven perfectamente en el iPad tanto en el Safari como en una app con una uiwebview. De hecho la galería de ejemplos que aporta Swiffy está muy bien, a ver que futuro nos depara el tema.

Mientras los editores HTML5 sigan tan verdes (veremos que pasa con el Adobe Edge), habrá que seguir convirtiendo Flash a HTML5.

Entonces entramos en el asistente de creación de app. Le doy el nombre a la app "barbacoa" :-) , y selecciono que voy a crear una app de iOS (iPhone) y Android. Selecciono entonces la imagen de fondo y el logo, que saldrán en la pantalla de inicio de la app. La plantilla "custom app" te permite tener un menu con 6 iconos. Definimos entonces lo que hará cada icono.

La lista de cosas que se pueden poner en cada menu (ver imagen) incluye lo siguiente: HTML, Audio Stream, Google Map, Contactos, Video Stream, Google Calendar, RSS, Galería de fotos, Llamar por tfno, Lista de videos, ebook, enviar correo, eventos, Twitter, navegar web, Noticias, Facebook y E-commerce.

La mayoría son bastante obvios, voy a probar 7 que pueden tener algo de miga: E-commerce, ebook, Eventos, Google Map, Contacts, Audio Stream y Video List

E-Commerce: Te permite subir productos, cada producto se compone de ID, Nombre, Precio y Foto. Los productos que subas salen en un listado en que en cada elemento pone el thumbnail de la foto, el nombre, precio, y dos botones "info" y "add to bag". En el asistente no se puede ver como funcionan.

E-Book: Te permite crear un libro, cada página la tienes que escribir en un rich-editor tipo Tinymce.

Eventos: Te saca una lista de eventos, que puede venir de un RSS feed o los puedes meter manualmente. Cada evento lleva Fecha, Nombre y Descripción.

Google Map: Es eso mismo, un mapa donde puedes ir poniendo marcadores. Cada marcador lleva Nombre, Longitud, Latitud, Detalles y URL.

Contacto: Una página para que pongas unos datos de contacto.  Lleva Nombre, Telefono, Dirección, Email y URL. No tiene relación con la libreta de direcciones del iPhone. Cada elemento es pinchable (el teléfono lleva a marcar, la dirección a Google Maps, etc..)

Audio Stream: Te permite hacer una lista de streams de audio a base de URLs (no se suben ficheros, evidentemente).

Video List: Te permite subir videos a la aplicación, que se muestran en forma de lista.

Una vez definidas las funciones de la app, procedemos a finalizarla. Entonces nos permite definir la splash screen (pantalla de inicio), y los datos para publicarla en el Appstore: Nombre, categoría, descripción, keywords, web de la app y el icono.

Llegamos a la pantalla de publicación. Como había seleccionado hacer la app para iPhone y Android, hay dos pantallas de publicación distintas. En la de iPhone, podemos seleccionar publicarla bajo nuestra cuenta de desarrollador de iPhone, para lo cual tenemos que generar los certificados correspondientes. Pero si no tenemos cuenta de desarrollador de iPhone, ellos nos hacen la cuenta de desarrollador a nuestro nombre por $199 + $99 anuales que cobra Apple, y la publican por nosotros.

La publicación Android es gratis total. Sólo tenemos que firmarla, y si lleva Google Maps, poner nuestra Maps API Key (el asistente de publicación lo hace todo).

Una vez publicadas, las apps no van directamente al Appstore o al Android Market, sino a un apartado de tu cuenta de ibuildapp llamado "Mis aplicaciones". Desde ahí puedes publicar en las correspondientes stores, o bajar los binarios para tu uso personal.

Asi que voy a probar la versión Android de la app que he creado. Me bajo el apk, y lo meto en mi Nexus One con Android 2.3.3.
La primera impresión es buena, se ve igual que se veía en el asistente. Pruebo las opciones: El ebook es como estaba previsto, listado de páginas - contenido. Probamos ahora el e-commerce, al dar al icono en el menu la app se congela. Vaya. Lo mismo pasa si voy a la opción Eventos.  El Google Map tampoco funciona. Vamos, por resumir, solo funciona el ebook, todas las demás opciones cuelgan la app, vaya fiasco.

Viendo el desastre de la app versión Android, voy a probar la versión iPhone. Después del lio habitual con los certificados, consigo hacer una publicación con un certificado ad-hoc (no voy a publicar este test en el Appstore evidentemente). ¿Pero, donde está mi "ipa"? Tarda un poco, pero acaba apareciendo en "Mis aplicaciones".
Lo descargo y lo instalo en mi iPhone 4 con el iOS 4.3.3. Como en la versión Android, el apartado ebook funciona bien.  Voy al apartado e-commerce, y entra, pero el producto que había puesto no sale en la lista. El apartado Eventos parece que va bien, el Google Map también aunque la descripción de las marcas no sale en la pantalla de ficha. Contacto va bien, y en Video List la lista sale vacía, yo había puesto la ficha de un video (aunque no lo había subido).

Resumen

Crear una app con iBuildApp solo te vale si necesitas una app que se pueda hacer con los "presets" que tienen, y aun así, es una lotería que funcione correctamente. Aun asi hay que reconocer que el asistente online que han montado está muy bien. ¿que ganan estos de ibuildapp si todo es gratis (excepto la publicación en Appstore)? Es un gancho para hacer apps mas complejas a medida. Es como los CMS tipo Wordpress o Joomla en web, todo el mundo sin saber programar se puede hacer una web con un CMS, pero tienen sus limitaciones, cuando necesitas algo específico tienes que ir a programación a medida, pues ibuildapps hacen los mismo, podriamos llamarlos los "CMS del movil".

Un kiosko táctil no es mas que un PC con pantalla táctil. Para hacer un multimedia para este tipo de dispositivos, nada como el Flash. Ahora que el Flash pierde terreno en web debido al HTML5, en los multimedia de sobremesa donde hay que generar un ejecutable (projector) sigue siendo el rey, por su efectividad y facilidad de uso.

En este post voy a poner algunos consejos a la hora de hacer projectors con Flash para kioskos táctiles:

Las dimensiones del Flash deben coincidir con las de la pantalla donde va a ser mostrado, por lo que antes de empezar hay que averiguar las características del kiosko donde va a ser mostrado. El Flash siempre se ejecutará a pantalla completa.

Los PCs que hay dentro de los kioskos suelen ser mini-PCs no muy potentes, por lo tanto no pasarse con los FPS del Flash, para que no vaya a saltos.

Hacer los botones del Flash gigantes. No quiero decir que los botones en sí sean grandes, sino que la superficie pulsable del botón (que puede tener alpha 0) debe ser lo más grande posible. Esto es así porque a veces las pantallas táctiles se descalibran con el uso, y si los botones son pequeños, al pinchar con el dedo la pantalla no lo podremos pulsar porque en cuanto se descalibre un poco ya no coincidirá el botón con el lugar donde hemos pinchado con el dedo.

No poner botones de salir de la aplicación. Parece una tontería, pero ya he visto algún multimedia de kiosko con el botón de "salir", ¿para que?

Poner el tipo de letra de los textos legible y bien grande, que los usuarios no tengan que pegar la nariz al kiosko para leerlo.

Poner un timer de inactividad, de manera que si el multimedia está sin tocar durante varios minutos, ejecute una animación o algo que llame a los usuarios.

Recordar meter un acceso directo del ejecutable del multimedia en el menu de inicio del Windows del PC que lleva el kiosko, para que al encender el kiosko ya arranque también el multimedia.

Cuidado con el audio. Antes de poner música o efectos de sonido al multimedia, hay que preguntar donde va a estar el kiosko, porque pueden molestar al público.

Y cuidado con el video: Para poner video a este tipo de multimedias, hay que seguir un par de consejos:

• Al ir a pantalla completa, debemos de poner al visor de video FLVPlayback el parametro fullScreenTakeOver a false. Además no debemos utilizar el FLVPlayback como componente visual, sino declararlo como objeto en el código, porque sino nos va a dar bastantes problemas.
• Si le ponemos el evento COMPLETE al FLVPlayback, hay que acordarse de quitarlo y volver a ponerlo si vamos a usar ese mismo componente para reproducir diferentes videos, pues "memoriza" el fin del primer video y nos puede dar "fines falsos" en los siguientes videos.

Lo primero es clonar el disco actual al nuevo disco SSD. Para ello hay que conectar el SSD por USB, se puede hacer de varias formas, por ejemplo metiendolo en una carcasa USB, pero yo prefiero utilizar el adaptador "Conceptronic Serial ATA & IDE to USB Adapter", que permite conectar "en caliente" cualquier disco por USB.

En la foto se puede ver cómo he conectado el SSD al ordenador mediante el Conceptronic Adapter.

Entonces clono el disco con el SuperDuper. Dos horas y media más tarde, ya está hecho. Evidentemente hay que mirar que en el disco origen haya menos datos que la capacidad del disco destino.

Una vez clonado el disco, hay que desarmar el Mac Mini. Tengo que decir que acojona más de lo que luego es. En Youtube se pueden encontrar tutoriales de como desarmarlo, y es bastante sencillo si se tiene un mínimo de cuidado.

La parte más delicada es la de la espátula, al abrir la carcasa. Una foto de mi Mac Mini abierto y la espátula usada:

A continuación se instala el disco, es bastante fácil. En la foto inferior se puede ver el disco SSD ya puesto en su habitáculo.

Pues nada, se vuelve a armar el aparato, y a continuación yo hago lo siguiente:

Resetear la PRAM: Es una buena costumbre resetear la PRAM cada vez que se instala nuevo hardware:

1. Reinicia el Mac y mantén pulsada la combinación de teclas Comando-Opción-P-R.
2. Manten pulsadas dichas teclas hasta que el Mac se reinicie dos veces (suene dos veces el arcorde de inicio).

Activar el TRIM: Actualmente el Snow Leopard no tiene soporte nativo para TRIM, pero se le puede activar con este fix: TRIM Enabler for Mac. Es muy importante activarlo para que la velocidad de lectura/escritura del SSD no se degrade con el tiempo.

Actualizar el firmware del SSD: Este paso no es tan importante, sería más bien un paso posterior si el SSD diera algún problema.

El resultado: No se como irá la cosa a lo largo del tiempo, pero la mejora inicial del rendimiento del sistema gracias al SSD es IMPRESIONANTE. Tanto como ver arrancar el Adobe Photoshop CS5 en 4 segundos, ver arrancar el Mac OS en 9 segundos, vamos de infarto, y encima sabiendo que el SSD consume menos corriente que cualquier HDD, no emite ruido en absoluto y es menos proclive a estropearse por un golpe al no tener partes móviles. Eso sí, es caro, pero en herramientas para la profesión no se puede escatimar.

Así que había que hacer creer al plugin que el feed prevenía de un Wordpress. Lo primero es añadir a la programación de tu feed todas las tags típicas de los feeds del Wordpress, incluso la que es:

http://wordpress.org/?v=3.0.1

No se si es necesaria, pero al menos te aseguras de que el plugin de Wordpress encontrará lo que busca.

Y a continuación, hay que modificar el .htaccess, puesto que el plugin va buscando una dirección del tipo:

http://enriquegonzalez.net?feed=rss2

La cual tiene que servir tu feed, por lo que se coloca en el .htaccess:

RewriteCond %{QUERY_STRING} ^feed=rss2$
RewriteRule ^(.*)$ rss.php

Y ya está, tienes tu feed en la portada de tu perfil de Linkedin mediante la "aplicación" Wordpress.

Referencia: 65011
Nombre y apellidos: Loree
Empresa: oupJboHYzHQPLIawhe
Teléfono: 1286843212349
Correo electrónico:fairplay@vidc.org
Mensaje:?Hey, youÂ’re the goto expert. Tahkns for hanging out here.

Lo primero que te preguntas es ¿qué interés puede tener el que hace esto? Haciendo spam a una persona que no conoce. En fin, la cuestión es que el formulario tenía validación de campos y captcha, pero eso no detenía al spambot, que seguía enviando los correos mediante ese formulario.

Dado que este tipo de ataques se suele hacer de forma indiscriminada, o sea, que el spammer no está mirando si pones alguna medida de seguridad para modificar su script de ataque, se pueden solventar sin problemas.

Hay varias cosas que suelen funcionar:

• Usar campos ocultos mediante CSS: El spambot autorellena los campos, e intenta poner los datos correctos según el nombre del campo (si se llama email, pone un email, si se llama telefono/phone, pone numeros) para evitar la validación, pero si rellena un campo real oculto mediante CSS y compruebas que ese campo ha sido rellenado, es que solo lo ha podido rellenar un spambot.
• Con lo comentado en el punto anterior, si no llamas a los campos de formulario con nombres comunes, o sea por ejemplo llamas al campo email "juanin", el spambot no sabrá qué tipo de datos usar para el relleno con lo que la validación lo detendrá.
• La "pregunta humana": Poner esto es un coñazo, pero puedes poner al final del formulario una pregunta para humanos tipo ¿Cuanto son 2 + 2? y comprobar antes de enviar.
• Si ya quieres hilar fino, puedes usar el API de Akismet, que permite comprobar si el mensaje que se va a mandar por email es spam o no. En forma de plugin es muy popular entre los usuarios de Wordpress, que evitan así que los machaquen a spam (sobre todo en los comentarios de los posts).

Hay muchos otros métodos, pero los spambots tampoco son tan listos.

Parece que ahora las cosas mejoraron un poco, al menos por una experiencia personal. Hace unas semanas, tuve un problema con un vendedor. Yo gané un item en la subasta, y el vendedor me dijo que pagara por transferencia (era español) en vez de por Paypal, por el tema de la comisión de Paypal. En este caso no me importó, a pesar de que la comisión de Paypal que el vendedor se ahorra, es comisión por transferencia bancaria que me cargan a mi. El vendedor parecía de confianza (votos positvos y tal).

La cuestión es que una vez pagado, recibo un email de eBay diciendo que han retirado el artículo porque el vendedor infringió una regla de eBay que no me quisieron decir. O sea, retiran el artículo una vez finzalizada la subasta y una vez pagado, y encima no me dicen por qué. Para más indignación, veo que la cuenta de eBay del vendedor también la han cancelado. Por supuesto, el vendedor dejó de contestar emails y demás.

El escenario parecía una estafa con la connivencia de eBay.

Lo primero que hice es abrir una disputa en eBay por mercancía no recibida, a pesar de que yo pensaba que no serviría para nada. A la vez, envíe emails al servicio de ayuda de eBay explicando lo que había pasado. Lo primero que me dicen por email es que al no haber pagado por Paypal, no me pueden devolver el dinero, que lo reclame en la entidad bancaria donde hice la transferencia. Esto no se puede hacer sin el permiso del dueño de la cuenta bancaria destino, permiso que evidentemente no tenía.

Como colofón, eBay me dice por carta que puedo denunciar el caso ante el servicio de delitos telemáticos de la Guardia Civil. Lo que parecía un lavado de manos total por parte de eBay, dió un vuelco unos días después. Ante mi insistencia por saber la identidad del vendedor, recibo una llamada de eBay (la primera que recibo de ellos en la vida, no sabía que ni tuvieran SAT telefónico) donde me dicen que no me pueden revelar quién es el vendedor pero que se han puesto en contacto con el para que se identifique.

Imagino que el vendedor recibió una llamada de eBay, porque al día siguiente, el vendedor que había estado callado todo este tiempo, de repente me envia un mail pidiendo perdon, contandome no se qué película, etc..

Al final todo se resolvió bien, pero la cuestión es que a pesar de todas las medidas de seguridad que uno toma, aun hay gente que sigue intentando estafar en eBay, que parece ser que al menos ahora es algo más seguro que antes.