WPML no funciona con mi tienda
El bug de nadie
"WPML no funciona con mi tienda."
Durante un par de años, ese fue uno de los tickets más frecuentes que recibíamos. También era uno de los menos útiles.
No nos decía qué había probado el cliente, qué plugin de tienda usaba ni qué significaba realmente "no funciona". Quizá los productos no se traducían. Quizá los precios sí se traducían pero el checkout no. Quizá todo parecía bien hasta que llegaba un pedido en el idioma equivocado.
Visto con perspectiva, creo que esos tickets fueron parte de la información más valiosa que recibió WPML en aquellos años. Solo que al principio no lo parecía.
Cada sitio de WordPress es una pila de software construida por gente que muchas veces nunca ha hablado entre sí. Un tema de una empresa, un plugin de tienda de otra, un plugin de traducción de una tercera, y quizá un maquetador encima de todo.
El cliente ve un solo sitio web.
Cuando algo se rompe, suele escribir a quien cree que debería poder ayudarle.
Lo complicado es que muchas veces el problema no está realmente en ningún producto concreto. Está en algún punto entre dos de ellos. Puede que cada producto funcione exactamente como pretendía su desarrollador, pero juntos producen algo que no funciona para el cliente.
Ese espacio entre productos no es realmente de nadie.
Así que, en la práctica, es de quien decida hacerse responsable de él.
De la queja al requisito
De 2013 a 2018 dirigí el programa de compatibilidad de WPML. El trabajo básico consistía en asegurarnos de que WPML funcionaba con los temas y plugins que la gente usaba de verdad.
El programa acabó cubriendo cientos de integraciones. Muchas de las más importantes las llevaba yo personalmente. Eran especialmente importantes porque, cuando se rompía una de las integraciones más populares, lo notábamos muy rápido.
Una de las primeras cosas que aprendimos fue que un ticket de soporte vago no es realmente un requisito.
"No funciona con mi tienda" tenía que convertirse en algo que pudiéramos probar.
Una página de producto debería tener su versión traducida. Esa versión debería mostrar el precio y la moneda correctos. El idioma del cliente debería mantenerse durante el carrito y el checkout. El email del pedido debería llegar en el idioma en el que compró.
Ahora teníamos algo concreto.
Podíamos probarlo, pasárselo a un desarrollador y explicarle a un autor externo exactamente qué no funcionaba. Antes de eso, lo único que teníamos era un cliente frustrado diciendo que algo estaba roto.
Buena parte del trabajo de compatibilidad era esta traducción, repetida una y otra vez: coger la descripción que hace un cliente de un problema y convertirla en algo sobre lo que dos equipos de desarrollo distintos pudieran trabajar de verdad.
La otra parte era trabajar con esos equipos.
La gente que construía los temas y plugins no trabajaba para nosotros. Tenían sus propios productos, prioridades y hojas de ruta, y no había ninguna razón para que pusieran automáticamente nuestro problema al principio de su lista.
Lo que solía ayudar era llegar con evidencia en lugar de con una petición vaga.
Aquí está el sitio. Aquí está la interacción exacta que falla. Esto es lo que creemos que tiene que cambiar por vuestra parte, y esto es lo que cambiaremos por la nuestra.
Eso hacía las conversaciones mucho más fáciles, y permitía que los ingenieros de ambos lados dedicaran su tiempo al problema real.
WooCommerce Multilingual salió de este tipo de trabajo. Veíamos una y otra vez los mismos problemas entre WooCommerce y WPML, y en algún momento tuvo más sentido construir algo específico para ese espacio entre los dos productos que seguir arreglando casos individuales.
Hacerse responsable del resultado
Hay dos cosas de aquellos años en las que todavía pienso.
Primera: al cliente no le importa mucho de quién es el bug. Y, sinceramente, no tendría por qué importarle.
Si el checkout de alguien está roto y le dices que es por culpa de un tema de terceros, puede que tengas toda la razón. Pero su checkout sigue roto.
A veces la forma más rápida de resolver el problema era arreglar algo por nuestra parte, aunque técnicamente la causa no fuera nuestra. El cliente no necesitaba una lección sobre quién era el responsable. Necesitaba que su sitio funcionara.
Segunda: no puedes hacerte cargo de verdad de un resultado que no mides.
Publicamos un boletín para clientes sobre nuestro trabajo de compatibilidad cada semana durante años. Tenía su lado de marketing, claro, pero también creaba una presión interna útil. Cada semana necesitábamos tener algo real que contar. Y los clientes podían ver lo que estábamos haciendo de verdad.
El programa empezó con dos personas y fue creciendo poco a poco hasta ser un equipo más grande. Recluté a gente de dentro del soporte de WPML, en parte porque ya conocían los problemas. Llevaban años leyendo tickets sobre cosas que "no funcionaban", así que tenían una idea bastante clara de dónde estaban los huecos.
Dónde encaja la IA
Hoy la IA puede ayudar con una parte de esto.
Dale a un agente de IA un ticket de soporte, la lista de plugins instalados y algo de información de depuración, y muchas veces puede convertir una queja vaga en una lista razonable de cosas que investigar. Es útil, y sin duda yo la usaría.
Pero hay una parte que la IA no puede resolver por ti.
No puede decidir quién debe hacerse responsable del espacio entre dos productos.
Eso sigue siendo una decisión humana.
Un sistema de IA puede decirte que el checkout falla porque dos plugins no están tratando igual la misma información. Alguien tiene que decidir todavía contactar al otro desarrollador, averiguar qué hay que cambiar y asegurarse de que el cliente acaba con un sitio que funciona.
Si construyes un producto que depende de los productos de otros, creo que eso es parte del trabajo.
Encuentra los huecos. Averigua qué tiene que ser verdad a cada lado. Y, cuando tenga sentido, hazte responsable del resultado aunque el código no sea del todo tuyo.
Esos tickets de soporte vagos son, muchas veces, donde se esconden esos huecos.
Merece la pena leerlos con un poco más de atención.