Puedes descargar las diapositivas de la charla (en catalán), o bien ver la presentación en WordPress.tv (también en catalán). ¡Espero que te gusten! Si, por el contrario, prefieres leer el contenido, lo tienes a continuación.

Introducción

Como he dicho anteriormente, mi objetivo era ayudar a aquellas personas que tienen un sitio web y se plantean añadir idiomas adicionales o que bien dudan si hacerlo multilingüe o no. Utilizando WordPress, por supuesto.

La primera pregunta que nos podemos hacer es si, hoy en día, tienen sentido los sitios web multilingües. ¿El motivo de la pregunta? La existencia de herramientas como Google que nos permiten traducir el sitio web de forma automática a prácticamente cualquier idioma. Evidentemente, esto ahorra costes y trabajo, pero… ¿Es lo que queremos?

El principal problema que tenemos si optamos por esta opción es que perdemos el control del mensaje que recibe nuestro cliente o target. No solo eso, sino que las herramientas de traducción automática, aunque hacen un gran trabajo, no son perfectas. Más de una vez hay errores de traducción. Y, aun si no los hay, no podemos elegir las palabras más adecuadas para comunicarnos con el receptor del mensaje.

Por lo tanto, aunque pienso que, por regla general, nos interesará controlar el mensaje, cada uno es libre de hacer lo que crea más adecuado en su contexto. Evidentemente, lo que diré a continuación deja de tener sentido si queremos que el sitio web se traduzca automáticamente.

Primer problema: ¡WordPress no es multilingüe!

Vamos a asumir que queremos un sitio web multilingüe donde controlemos el mensaje que llega a nuestro target. Y que tenemos un sitio web (o queremos tenerlo) en WordPress. La primera dificultad que encontramos es que el núcleo de WordPress solo permite tener un solo idioma. Es decir, podemos elegir qué idioma queremos de entre todos los disponibles, y podemos tener diferentes de ellos instalados que permitan cambiar el idioma del back-end según la configuración de cada usuario, pero el sitio web en sí tendrá uno solo.

¿Podemos solucionarlo? Sí. ¿Cómo? Con plugins (o extensiones) de terceros.

Solución: Plugins para crear sitios web multilingües

La siguiente decisión que debemos tomar es qué plugin elegir. Los más conocidos son los siguientes:

• WPML
• Polylang
• TranslatePress
• WeGlot
• MultilingualPress

Lo que ocurre es que muchos de estos plugins (WPML, WeGlot y MultilingualPress) son de pago y no tienen una versión gratuita en el directorio de WordPress, o la versión gratuita es bastante limitada. Estoy asumiendo que, cuando se empieza, los recursos son limitados, y por tanto, interesa optar por versiones gratuitas de plugins aunque tengan sus limitaciones.

Por lo tanto, de todos estos, nos quedan dos. Polylang y TranslatePress.

Polylang vs TranslatePress

Aunque los dos plugins nos permiten llegar al mismo resultado, también tienen una serie de diferencias. A continuación examinaremos los puntos en común y entraremos en detalle en las diferencias.

Similitudes

Como puntos en común principales, Polylang y TranslatePress tienen lo siguiente:

• Siguen un modelo freemium. Es decir, hay una versión disponible de forma gratuita en el repositorio de WordPress con una serie de funcionalidades básicas; para funcionalidades más avanzadas, se requiere optar por la versión de pago.
• Ambos permiten tener un sitio web en varios idiomas de forma gratuita.

Diferencias

Aquí es donde el tema comienza a ser interesante. Los dos plugins son muy diferentes entre sí, y optar por uno u otro dependerá de las necesidades que tengamos. Empecemos.

Número de idiomas

La versión gratuita de TranslatePress solo nos permite tener un idioma adicional. En cambio, Polylang no pone límites en el número de idiomas en su versión gratuita.

Idioma base

Se puede decir que los dos plugins funcionan con un idioma base, o idioma por defecto. Sin embargo, las implicaciones de esto son completamente diferentes en ambos casos.

Polylang permite generar contenido en cualquiera de los idiomas que tengamos instalados, y no tiene ninguna limitación al respecto. Si tenemos el sitio web en catalán, español e inglés, podemos crear un contenido que esté únicamente en inglés y que no tenga traducción, aunque el idioma base sea el español (ejemplo real de este sitio web). Esto nos da mucha flexibilidad y libertad a la hora de crear contenido.

Con TranslatePress la historia cambia. Es necesario crear el contenido en el idioma base, y luego se puede agregar, si se desea, la traducción. No se puede crear contenido que no esté en el idioma base. El motivo es que, internamente, las traducciones de TranslatePress funcionan como un diccionario. Si tenemos el sitio web en inglés y español, y el inglés es el idioma base, lo que hará TranslatePress cuando accedamos al contenido en español es buscar la traducción de cada uno de los textos, partiendo del inglés. Evidentemente, si no hay versión en inglés, no podemos buscar la traducción.

Una consecuencia de esto es que si cambiamos los textos en el idioma base en TranslatePress, se pierde también la traducción. Se puede recuperar fácilmente porque sigue guardada, pero es necesario volver a agregarla (aunque sea reutilizando la existente) manualmente.

El precio de la flexibilidad

La flexibilidad de Polylang no es «gratuita». A nivel de backend (o de gestión), abruma mucho. Cada vez que creamos un contenido, por ejemplo una página o una entrada del blog, nos permite asignarle un idioma. Si tenemos tres idiomas, y lo generamos en esos tres, significa que veremos tres páginas o tres entradas de blog. Por lo tanto, el volumen de contenido crece rápidamente.

En cambio, en el caso de TranslatePress, solo vemos una página o una entrada de blog, independientemente de los idiomas adicionales que tengamos (aprovecho para recordar que la versión gratuita solo permite un idioma extra). Por lo tanto, a nivel de gestión es mucho más limpio.

Hay que tener en cuenta, sin embargo, que a la hora de decidirse por uno u otro plugin, deberían pesar mucho más las limitaciones a nivel de cambios de textos, por ejemplo, que esto.

Maquetación del contenido

Otra consecuencia de estas diferentes formas de funcionar es a nivel de maquetación del contenido. En el caso de Polylang, como ya mencioné, un contenido para el blog en tres idiomas es, en realidad, tres entradas. Esto hace que a la hora de crear y maquetar el contenido, tengamos libertad completa y absoluta. Incluso podríamos escribir contenido diferente en cada idioma y vincularlo como si fuera el mismo.

En cambio, TranslatePress nos obliga a respetar la maquetación y estructura del texto, aunque permite cambiar las imágenes en función del idioma.

Metadatos de las imágenes y SEO

Polylang nos ofrece la opción de traducir los metadatos de las imágenes. Los metadatos son información relativa a la imagen que puede ser útil, por ejemplo, para personas con diversidad funcional o si la página tarda en cargar. Por ejemplo, es una buena práctica que todas las imágenes tengan un atributo «alt» porque es la información que se mostrará si la imagen no carga o si la persona es ciega. Además, la inclusión de estos metadatos puede ayudar a posicionar la web y las imágenes en los buscadores. Por tanto, es bueno traducir estos metadatos (aunque es un rollo y una tarea laboriosa, no os engañaré).

En cuanto al SEO, aunque en un principio Polylang no incluye ninguna herramienta para ayudar en el posicionamiento, se integra perfectamente con Yoast SEO, y la versión gratuita de ambos plugins nos permite configurar palabras clave, previsualizaciones, etc. para cada idioma.

TranslatePress, por otro lado, no ofrece ninguna de estas opciones en su versión gratuita. No obstante, si se opta por su versión de pago, sí las ofrece.

Creación de un e-commerce con WooCommerce

Y aquí es donde cambia la cosa. Si con lo que hemos visto hasta ahora parecía que la versión gratuita de Polylang ofrecía más funcionalidades, aquí cambian las tornas. Con Polylang, si queremos tener una tienda en varios idiomas mediante WooCommerce, hay que optar por la versión de pago.

En cambio, la versión gratuita de TranslatePress permitirá traducir sin problemas toda la información de los productos y los correos que se envían.

Incorporación de herramientas de traducción automática

La versión gratuita de TranslatePress permite introducir una clave API para poder utilizar herramientas automáticas de traducción como DeepL o Google Translate. Eso sí, habrá que pagar por el uso que se haga de estas herramientas, pero es un coste externo a TranslatePress. Con el fin de minimizar este coste, TranslatePress descarga la traducción solo una vez y luego permite editarla.

Polylang no ofrece este tipo de integración.

Resumen de TranslatePress vs Polylang

Aunque yo tengo mis preferencias personales, creo que la decisión de utilizar un plugin u otro depende más de las necesidades del proyecto. Suponiendo que no se dispone de presupuesto para invertir en las versiones de pago, a modo de resumen se podrían hacer las siguientes recomendaciones:

Compatibilidad con otros plugins y temas

Otro aspecto a considerar es la compatibilidad de Polylang y TranslatePress con otros plugins y temas. En general, suelen funcionar bien, pero hay algunas cosas que hay que tener en cuenta. Hay que tener en cuenta que lo que explicaré a continuación se basa en mi propia experiencia y no he realizado comprobaciones exhaustivas. Por tanto, podría ser que en otras situaciones los resultados sean diferentes.

Polylang y plugins

Como he mencionado anteriormente, en general no he tenido muchos problemas al utilizar Polylang con otros plugins. Sin embargo, la excepción más notable es el caso de WP-Portfolio. En su momento, investigué mucho y parecía ser uno de los mejores plugins para crear portafolios (de cualquier tipo) en el sitio web.

Sin embargo, con un sitio web multilingüe, es un desastre. No filtra correctamente según el idioma y se mezclan los proyectos en diferentes idiomas. Aunque encontré una solución temporal, decidí renunciar a utilizarlo porque no era la forma correcta de hacer las cosas, y a largo plazo habría causado problemas.

Polylang y temas

Personalmente, me gustan mucho los temas genéricos como Astra, OceanWP, Kadence y GeneratePress, que son muy configurables desde el back-end de WordPress sin necesidad de tocar código, y que sirven para cualquier tipo de web.

Cuando estaba creando esta web, en un primer momento decidí utilizar OceanWP. Mi sorpresa fue enorme cuando vi un aumento muy grande del tiempo de carga de la web en el momento en que le añadí Polylang. Lamentablemenete me vi obligada a cambiar de tema.

Con el resto de temas, los tiempos eran mucho más razonables. En la tabla que aparece a continuación se ven los tiempos, obtenidos con el plugin CodeProfiler. Los plugins probados en cada caso eran exactamente los mismos, lo único que cambia es el tema.

TranslatePress y temas

Al tener que hacer esta ponencia en la WordCamp BCN 2023, decidí hacer pruebas también con TranslatePress y los temas mencionados anteriormente. A diferencia de Polylang, no hubo problemas significativos con ninguno de ellos y, en general, los tiempos fueron mejores. De hecho, las diferencias entre los temas son mucho menores que con Polylang.

Cabe mencionar, sin embargo, que las condiciones de prueba no fueron las mismas que en el caso de Polylang, ya que las realicé en otro sitio web, por lo que no puedo afirmar categóricamente que TranslatePress sea más rápido.

TranslatePress y plugins

Mi experiencia con TranslatePress es mucho más limitada que con Polylang. No he encontrado problemas con ningún plugin, pero por otro lado tampoco es demasiado significativo, ya que solo he trabajado con un sitio web corporativo que no tenía demasiadas complicaciones.

El proceso de traducción

Ahora que hemos visto los detalles de los dos plugins gratuitos, me gustaría compartir el proceso de traducción que sigo cuando quiero publicar contenido en este sitio web, que está en catalán, español e inglés. Tened en cuenta que este proceso se basa en el uso de Polylang, y que no siempre sigo al 100% el orden mencionado (aunque sí realizo todas las tareas descritas).

1. Redacción del texto en un Google Doc, en inglés. Comienzo por la versión en inglés porque me resulta más fácil empezar en inglés y luego lograr que el texto suene natural en catalán y español, que al revés.
2. Traducción del texto al catalán y español mediante Google Translate. Como Google Translate está integrado en Google Docs, obtengo la traducción con un par de clics.
3. Revisión manual de las traducciones, para asegurarme de que el mensaje se transmita correctamente, no haya errores y suene natural.
4. Maquetación del texto en uno de los idiomas (por ejemplo: inglés), y búsqueda de fotos.
5. Traducción de los metadatos de las imágenes seleccionadas. Esta parte es muy aburrida y pesada, no os voy a mentir.
6. Duplicación del contenido maquetado con un plugin, como por ejemplo Yoast Duplicate Post. De esta manera tengo la maquetación hecha.
7. Cambio del idioma de este duplicado.
8. Sustitución del texto por la traducción.
9. Sustitución de las imágenes. Aquí realmente no cambio la imagen, sino que me aseguro de que se referencien los metadatos adecuados según el idioma.
10. Enlazado de las traducciones, para garantizar que si un usuario desea cambiar el idioma del sitio web, lo lleve a la versión correcta del texto.

Evidentemente, los pasos 6-9 se deben repetir para cada idioma. Por si no queda claro, como se puede ver es casi duplicar o triplicar el trabajo que supone tener un sitio web en un solo idioma.

Por otro lado, yo normalmente opto por publicar los contenidos cuando los tengo en los tres idiomas. Con Polylang, sin embargo, no hay nada que impida publicarlos primero en un idioma y luego en los demás. Con la versión gratuita de TranslatePress esto no es posible. Cuando se publica, se publica todo.

Herramientas del políglota

A continuación quiero compartir con vosotros una serie de herramientas que os pueden ser útiles si decidís tener un sitio web multilingüe.

• Plugin de traducción. Como hemos visto, si queremos un sitio web multilingüe en WordPress, debemos empezar eligiendo un plugin de traducción.
• Traductor. Además de Google Translate, tenemos otras opciones como DeepL, ChatGPT, Apertium, etc.
• Duplicador de contenidos, como Yoast Duplicate Post.
• LocoTranslate. De esta herramienta no he hablado, y también es muy útil. Vale la pena comentarla con más detalle, cosa que haré a continuación.

Y sobre todo, lo más importante… ¡Hace falta mucha paciencia y dedicación!

LocoTranslate

LocoTranslate es un plugin que permite editar las traducciones de los plugins y los temas. Es muy útil cuando nos encontramos con plugins o temas que no están traducidos en el idioma de nuestro sitio web, o que lo están pero no nos gusta la traducción realizada. Además, tiene la ventaja de no sobrescribir las traducciones existentes, sino que funciona con un sistema de prioridades:

1. Primero verifica si hay una traducción realizada por nosotros del texto en cuestión. En caso de que exista, la utiliza.
2. Si no existe, busca la traducción propia del plugin o tema.

Por lo tanto, aparte de beneficiarnos de las traducciones existentes, cuando se actualicen las traducciones del complemento o tema, no afectará a las traducciones que hayamos realizado. Si se editara directamente la traducción del plugin o tema, se perdería en el momento en que se actualizara la traducción «oficial».

Conclusiones

Viendo todo esto, ¿vale la pena tener un sitio web multilingüe? Pues como todo en esta vida (o casi todo), depende… A continuación, hago una valoración de diferentes aspectos que se deben tener en cuenta.

En primer lugar, se requiere una gran dedicación. Como ya he mencionado, un sitio web multilingüe implica mucho trabajo. Aunque la idea sobre la que escribir solo se piensa una vez, la redacción y maquetación de los textos suponen casi multiplicar el tiempo de dedicación de un sitio web monolingüe por el número de idiomas.

Y aquí es donde entra en juego el factor que considero clave: la MOTIVACIÓN. Es necesario tener muy claro el por qué queremos un sitio web multilingüe. Si no lo tenemos claro, es probable que perdamos las ganas a medio proceso. La motivación puede ser económica, de marketing, intrínseca o personal, entre otras.

En mi caso, decidí tener un sitio web en tres idiomas principalmente por un motivo personal. El catalán es mi lengua materna y sentiría que no me representa si no lo tuviera en este idioma. Lo tengo en castellano porque vivo en una región bilingüe y me permite llegar no solo al resto de España, sino también a Latinoamérica. Por último, considero importante tenerlo en inglés, ya que no solo me abre potencialmente al mercado, sino que también dice muchas cosas sobre mí:

• Mi compromiso con los idiomas
• Mi nivel o capacidad para hablarlos
• Es un reflejo de mi dedicación

Otro aspecto a considerar es que no es necesario traducirlo todo, sobre todo si se utiliza la versión gratuita de Polylang, que no nos obliga a nada. Una forma «fácil» de tener un sitio web multilingüe es traducir la información de las páginas o la información estática (sobre nosotros, página principal, servicios, contacto, etc.) y tener el blog en un solo idioma. De esta manera, se realiza el trabajo de traducción al principio y ya está.

Finalmente, también hay que recordar que aunque podemos comenzar con un sitio web multilingüe sin tener que pagar por los complementos de traducción, a medio-largo plazo es posible que esta situación cambie y, por lo tanto, haya un posible coste económico adicional. Por ejemplo, si optamos por TranslatePress, si en algún momento queremos agregar un tercer idioma, deberemos optar por la versión de pago del complemento. Lo mismo ocurre si utilizamos Polylang y queremos agregar una tienda.

Créditos

The post Consejos para crear una web multiidioma appeared first on Dandelium Studio.

• ¿Existen plugins para listar propiedades estilo inmobiliaria en WordPress?
• ¿Son una opción viable?
• ¿Son la mejor opción? ¿O hay alternativas más adecuadas?

En esta entrada explico el proceso de investigación que seguí y mis resultados.

Para los que tengáis prisa, aquí está el resumen: se puede hacer, hay plugins que funcionarían para un sitio web de este tipo, pero no estoy segura de que usar WordPress sea la mejor opción. Dependerá del alcance del proyecto y sus requisitos.

Requisitos

Mi clienta quería un sitio web simple para gestionar algunas propiedades. Las propiedades estarían disponibles para alquiler, venta y, en un futuro, quizás para alquiler vacacional. Otro aspecto importante a tener en cuenta son los idiomas: aunque inicialmente la web podía estar en un único idioma (castellano) era necesario tener la posibilidad de añadir otros idiomas como el catalán. Si es posible, también le gustaría poder publicar los listados en otros portales inmobiliarios.

Por otro lado, las funcionalidades IDX y MLS no son necesarias. De igual forma, dado que la clienta estará trabajando por su cuenta, no es necesario asignar agentes a cada propiedad.

¿Se puede hacer? ¿Qué plugins hay?

Para responder a estas preguntas, realicé un par de búsquedas en Google e investigué el directorio de plugins de WordPress. Encontré artículos como el escrito por la gente de Astra. Sin embargo, está desactualizado: algunos de los plugins recomendados han sido descontinuados o eliminados del directorio de WordPress debido a problemas de seguridad. Sin embargo, me sorprende que nadie verificara la información después de revisar el artículo.

Uno de los primeros problemas con estos plugins fue que la mayoría de ellos están en inglés. Esto no es un problema para mí, pero ciertamente es un inconveniente para mi cliente, ya que el sitio web tiene que estar en español.

En cualquier caso, después de investigar, determiné que solo había dos plugins que cumplían con los requisitos:

• Realtyna WPL
• Estatik

Mi primera elección fue Estatik, por dos razones principales:

• Las reseñas de Estatik me parecieron en general mejores que las de Realtyna. Esto es una opinión subjetiva basada en mis impresiones, y no en datos objetivos.
• Tiene traducción al español.

Sin embargo, después de probar Estatik, me di cuenta de que tiene algunos problemas y por eso también investigué la otra opción, Realtyna WPL.

Hay que tener en cuenta que en ambos casos usé la versión gratuita de estos plugins, pero haré alguna referencia ocasional a la versión de pago.

Estatik

Detalle de la propiedad

Página principal

Vista en cuadrícula

Vista en formato de lista

Empecé instalando Estatik en un entorno de desarrollo local para evaluar sus funcionalidades. El resumen de mi experiencia es el siguiente:

Ventajas de Estatik: 

• El aspecto visual por defecto; es muy bonito.
• Viene con vistas de lista, cuadrícula y mapa y funcionan sin tener que configurarlas.
• La capacidad de agregar campos personalizados y valores para estos.
• Compatible con Polylang (para sitios web multilingües).
• En general, es fácil de usar y entender cómo funciona.
• Se integra con Google Maps.
• Agrega automáticamente un formulario debajo de cada propiedad listada para obtener más información sobre la misma.
• Se integra con otros plugins de SEO, como Yoast SEO.
• Es posible importar propiedades de demostración, que son muy útiles para comprender las capacidades del complemento.

Desventajas de Estatik:

• La última actualización tuvo lugar hace aproximadamente un mes. Sin embargo, el soporte técnico es un poco impredecible. Me puse en contacto con ellos a través del foro de soporte y su sitio web. Mi mensaje del foro no recibió ninguna respuesta, pero me ayudaron por correo (tardaron alrededor de una semana en responder).
• Falta documentación o está incompleta.
• Falta de funcionalidades en la interfaz de usuario. Por ejemplo, no hay una forma fácil de traducir los diferentes campos usando la interfaz. La única forma de traducirlos y vincular la traducción es acceder manualmente a la pantalla de edición de taxonomía usando los parámetros correctos en la URL. Este es un gran inconveniente si el propio cliente quiere actualizar el sitio web por su cuenta.
• No hay alternativas a Google Maps. Si no se utiliza Google Maps, las direcciones no se pueden agregar manualmente y la función de búsqueda no funciona para las ubicaciones. Después de escribir esto, recibí una respuesta de su equipo de soporte y me informaron de un truco para poder ingresar las direcciones manualmente. Si bien funciona, la función de búsqueda por localización sigue sin hacerlo.
• La versión gratuita agrega un pequeño aviso debajo de la propiedad. Se puede eliminar manualmente usando CSS.
• La traducción al español está lejos de ser perfecta y necesita ajustes manuales.

Realtyna WPL

Vista de la propiedad. No es así como se ve por defecto; ya se han aplicado algunos cambios de diseño.

Vista en cuadrícula. No es así como se ve por defecto; ya se han aplicado algunos cambios de diseño.

Cuando me convencí de que Estatik funcionaría para las necesidades de mi clienta, me di cuenta de que no era posible buscar por ubicación usando campos personalizados. Como resultado, decidí evaluar también el plugin Realtyna WPL. El resumen de mi experiencia es el siguiente.

Ventajas de Realtyna WPL:

• Las vistas de lista, cuadrícula y mapa están disponibles y funcionan sin necesidad de configurarlas.
• La capacidad de agregar campos personalizados y valores para estos campos personalizados.
• Se integra con Google Maps.
• Aunque no afirman que el plugin esté en español, en realidad la traducción está hecha en un 60% en el momento de escribir este artículo, lo que realmente facilita las cosas.
• Ofrece sus propias funcionalidades de SEO.
• Es posible importar listados de demostración, que son muy útiles para evaluar y entender las capacidades del plugin.
• Se puede agregar automáticamente un formulario a cada propiedad para que sea más fácil para el cliente potencial ponerse en contacto.
• Puede crear automáticamente un código QR para cada propiedad. Me pareció muy interesante.

Aspectos neutrales de Realtyna WPL:

• Ofrece un gran control sobre los campos. Permite agregar campos personalizados, sus valores, y también ofrece muchas opciones de configuración diferentes. En cierto sentido, esto es una ventaja (como ya he indicado antes), pero al mismo tiempo, es difícil entender cómo funciona todo de un vistazo y puede resultar abrumador.

Desventajas de Realtyna WPL:

• Compatible con sitios web multilingües, pero solo en la versión de pago.
• El diseño por defecto se ve anticuado. Si la web no usa uno de los temas propios de Realtyna WPL, será necesario crear una plantilla o cambiar el CSS para que las cosas se vean decentes. Por ejemplo: al mostrar algunas imágenes no se respeta su ratio y, en consecuencia, las imágenes suelen verse estiradas.
• Sensación de complejidad al usarlo.

¿Cuál es mejor? ¿Estatik o Realtyna WPL?

Después de analizar estos plugins, creo que ambos tienen sus ventajas y sus inconvenientes, y elegir uno u otro dependerá de los requisitos. Si es suficiente con un sitio web inmobiliario simple y no hay problema en usar Google Maps, Estatik sea probablemente la mejor opción. También es más recomendable si interesa tener la web configurada lo antes posible.

Sin embargo, en el momento de escribir este artículo (febrero de 2023), el soporte de Estatik es un poco impredecible. Es posible que tarden mucho en responder a las preguntas, si es que llegan a hacerlo. En mi caso particular, estoy muy agradecida de que respondieran a mi consulta y me dieran cierta solución / truco para solucionar el problema al que me enfrentaba. Por otra parte, no soy una clienta que haya pagado y entiendo que tengan otras prioridades, especialmente si el equipo es pequeño. Así que hay que tener esto en cuenta si se elige Estatik.

Por otro lado, si se buscan funcionalidades más avanzada, escogería Realtyna WPL. Sin embargo, su configuración llevará más tiempo y probablemente será necesario hacer cambios en el diseño del sitio web, a diferencia del caso de Estatik, donde los cambios serán mucho menores (si el estilo encaja).

Conclusiones

Al comienzo de esta entrada planteé algunas preguntas básicas sobre WordPress y su uso para un sitio web inmobiliario. Son las siguientes:

¿Existen plugins inmobiliarios para WordPress?

La respuesta a esto es clara. Sí los hay. Las dos opciones principales son Estatik y Realtyna WPL.

¿Son una opción viable?

Sí. Con estos complementos, es posible crear un sitio web funcional para una inmobiliaria usando WordPress.

¿Es WordPress la mejor opción para crear una web inmobiliaria?

No tengo una respuesta clara a esta pregunta. Depende de las funcionalidades que se necesites y de los mercados en los que operará el sitio web.

Lo que sí creo es que estos plugins no son especialmente adecuados para el mercado español. Por ejemplo, ninguno se integra con portales inmobiliarios ni incluye la clasificación de consumo energético en la versión gratuita. Además, las traducciones están incompletas o requieren ajustes manuales.

Durante mi proceso de investigación, comprobé algunas de las soluciones utilizadas por las agencias inmobiliarias en España. Su modelo de negocio es completamente diferente al de un sitio web que utiliza WordPress:

• Sus paquetes suelen incluir alojamiento y el software para el sitio web.
• Los clientes pagan una tarifa mensual o anual. El costo es más bajo al principio (ya que el cliente no tiene que pagar una tarifa de configuración del sitio web), pero probablemente sea más alto a largo plazo.
• No es posible probar el software en un entorno propio de desarrollo. La única forma de verlo en acción es solicitando una demostración o visitando sitios web que lo utilicen.
• La configuración del sitio web generalmente está incluida en la tarifa.
• La mayoría de estos incluyen la opción de conectarse a otros portales inmobiliarios.

Por lo tanto, si estás en el mercado español y deseas crear un sitio web inmobiliario para una agencia mediana o grande, probablemente sea mejor otra solución. Por otro lado, si trabajas por tu cuenta y no quieres tener un sitio web demasiado complejo, probablemente tengas suficiente usando WordPress + un plugin. Sin embargo, hay que tener muy en cuenta sus limitaciones.

The post Crear una web inmobiliaria con WordPress appeared first on Dandelium Studio.

Si ya estáis familiarizados con WP-Portfolio, podéis ir a mis impresiones.

Como tengo un negocio creando sitios web con WordPress, es muy importante que tenga un portafolio para mostrar mi trabajo. Es una forma de demostrar lo que puedo hacer y generar confianza en lo que hago, y que el cliente decida si el tipo de trabajo que realizo se alinea con sus intereses y objetivos.

Una descripción general de WP-Portfolio

Últimamente he estado buscando un complemento para crear un portafolio. Un plugin que vi recomendado en todas partes para ello es WP-Portfolio, incluso dicen que es el mejor. Lo que distingue a WP-Portfolio de los demás plugins es que, cada vez que crea un elemento para el portafolio, se puede elegir entre 4 tipos diferentes: imagen, video, sitio web o página individual. Los tipos de imagen, video y sitio web vinculan sólo un elemento, es decir, una única imagen, un video o sitio web. Para el tipo “sitio web”, incrusta el enlace en un iFrame, de modo que el usuario nunca abandona la web original. 

El tipo de página individual, por otro lado, es muy interesante porque simplemente tiene el aspecto de una página de WordPress, y se le puede añadir tanta información como una desee. Por ejemplo, si eres fotógrafa, puedes usarlo para crear una galería de imágenes de una sesión con un cliente (en lugar de tener una sola imagen). Si os dedicáis a la creación de sitios web, podéis usarlo para explicar cómo surgió el proyecto (echad un ojo a mi portafolio para ver un ejemplo). En mi caso particular, esta característica, o algo similar a ésta, era imprescindible para poder explicar y contextualizar bien los proyectos.

Desgraciadamente, WP-Portfolio no tiene una versión gratuita y, como resultado, no hay forma de probarlo antes de pagar. WP-Portfolio está desarrollado por Brainstorm Force, la compañía detrás del conocido tema Astra. Llevo un tiempo usándolo y estoy muy contenta con él, así que finalmente me lancé y compré WP-Portfolio, junto con Astra Pro, en el Essential Bundle).

Impresiones de WP-Portfolio

Mi primera impresión después de comprar el plugin y acceder a la página de descarga fue que el WP-Portfolio no se actualiza regularmente. Esto no es un problema en sí mismo, ya que si funciona correctamente, ¿por qué cambiarlo?

Sin embargo, después de instalarlo, comencé a encontrar los problemas reales. No funciona bien con sitios web multilingües que utilizan Polylang. ¿El problema? Las categorías no están filtradas correctamente en la página del portafolio y todas se muestran independientemente del idioma seleccionado.

Además de esto, no ofrece la posibilidad de utilizar un bloque de Gutenberg para incluir el portafolio en una página. Tienes que usar un shortcode. Nuevamente, esto no es necesariamente malo, pero confirma mi primera impresión de que no se mantiene actualizado. La mayoría de los complementos hoy en día incluyen ambas opciones: un bloque y un shortcode.

Sin embargo, lo que al final me hizo decidir no usarlo en mi sitio web fue el proceso de carga del portafolio. A pesar de tener solo un proyecto, se veía un icono de carga al acceder a la página principal de portafolio. Probé los tiempos de carga generales usando WP-Portfolio y otra opción (que mencionaré más adelante) y eran similares, pero no pude pasar por alto el hecho de que se veía un ícono de carga. Como usuaria de un sitio web, me sorprendería mucho ver un símbolo de carga para luego revelar solo un elemento; verlo me da la impresión de que el sitio web es lento, aunque no lo sea. Y, además, el plugin obtiene previamente el contenido de los elementos que carga en la página de portafolio, lo cual es totalmente innecesario.

Alternativas a WP-Portfolio

Si os encontráis en una situación similar, es posible que os preguntéis qué alternativas existen. Puedo ofrecer dos: la primera es Visual Portfolio, Posts & Image Gallery, de nK. La versión gratuita de este plugin tiene muchas más funciones que WP-Portfolio, incluída una vista de tipo Lightbox para las imágenes, y funciona bien en el front-end de los sitios web que usan Polylang. Sin embargo, hay un bug en el back-end. Cada vez que usa bloques de Gutenberg para insertar galerías del portafolio, sólo muestra una barra de administración y no una vista previa del contenido. Como resultado, para tener una idea del aspecto final de la página, hay que acceder contínuamente a la vista previa. Sin embargo, tened en cuenta que oficialmente no garantizan un funcionamiento correcto con Polylang, sólo con WPML.

La otra opción es utilizar Powerfolio, un plugin que crea un elemento de tipo portafolio e incluye bloques adicionales de Elementor para mostrar el contenido. Esta opción requiere, por lo tanto, usar Elementor (no es necesario pagar por la versión Pro) para mostrar el portafolio. Usando esta combinación de plugins no encontré errores: pude obtener una vista previa del contenido mientras lo editaba y todo se veía bien en el front-end. Cada elemento del portafolio es en realidad una página, por lo que me da la flexibilidad y la libertad de crear la página de cada proyecto a mi gusto, sin límites. Por este motivo al final opté por esta solución. Todavía estoy indecisa sobre Elementor, ya que me gusta mantener mi sitio web lo más «ligero» posible, pero por el momento estoy bastante satisfecha con esta solución, y los tiempos de carga son similares a los de WP-Portfolio.

Conclusión

En resumen, me gustaría que alguien hubiera comentado estas carencias en relación a WP-Portfolio, ya que de saberlo posiblemente no habría pagado por él. Dicho esto, creo que es bueno conocer las tecnologías existentes para poderme adaptar a las necesidades de cada cliente, y WP-Portfolio tiene también muchas cosas buenas. Dime, ¿tienes un portafolio en tu web? ¿Usas algún plugin para crearlo? ¿Cuál? Cuéntamelo en los comentarios.

The post Por qué no puedo recomendar WP-Portfolio: una reseña appeared first on Dandelium Studio.