Xaraya 1.1 is out, with some big changes. For example, the Adminpanels module is out, and the autentication system have been rearranged. Of course, a lot of bugs have been fixed, and they work a lot in templates. And finally instalation is translaed into spanish .

I think they are doing a god work, but there are some work to do, and i’m working on it.

You can download the spanish translation (only core release) here.

Original text

Spanish text

English text

As you can see, the module accept the format <lang=”xx_XX”>…</lang> and [lang=”xx_XX”][/lang], and now I’m working to create a Blocklayout tag to show other available languages or allow a GET “lang” parameter.

I’ve been reorganizing mi ideas, and investigating how other CMS and blogs do it, and yesterday i was talking with MichelV and Jojode in channel #support of Xaraya IRC when i saw the light

My idea is the creation of an utility module, Multi Language Content (or MLContent), that can be hooked by any other content module and let it show translated content. It avoid the complexity of integrate it with core, and let site admin decide what module can handle translations. It also allow all users use it in recent 1.0.x releases of Xaraya.

The key is that it must be simple. In my previous post i give some ideas, but they are very complex and require a lot of code and processing. Searching how other CMS do it I found some modules to Wordpress that allow multi language content, such as Polyglot (the one we’re using in this blog), and the idea is so simple that i loved it . They use a tag such as < lang_xx >…< /lang_xx > or [ lang_xx ]…[ /lang_xx ], and it shows or hide the content based on marqued current locale or get var, all in the same text area, and give an output code to show a list of flags to can view the content in other languages present in the content.

Talking with MichelV we thought that it could also be easily done parsing translated strings with (x)html compliance code, using lang or xml:lang (for XHTML 1.1, that eliminates lang attribute from the DOCTYPE) attributes. Then, the module parse all content and show or hide it depending of the current user locale and the attributes of the code. We only need to avoid translate or parse nested tags with the attributes (to let editors create accessible and semantic code). It also could be easily implemented in WYSIWYG editors such as TinyMCE.

It could be easily done with javascript and DOM, even with CSS, but i think that it’s a best work to the server (due to leack of support of DOM and css selectors in some browsers), so i’m trying with DOM classes of PHP. I’ll write here all advances that i get with this module

En un artículo anterior escribí sobre la idea de eliminar el MLS del núcleo de Xaraya 2.0 y la necesidad de un módulo que tradujera el contenido dinámico, así como la GUI.

he estado reorganizando mis ideas, e investigando cómo lo hacen otros CMS y blogs, y ayer estaba hablando con MichelV y Jojode en el canal #support del IRC de Xaraya cuando vi la luz

Mi idea es la creación de un módulo de utilidad, Multi Language Content (o MLContent), que pueda ser enganchado por cualquier otro módulo de contenido y le permita mostrar el contenido traducido. Esto evita la compeljidad de integrarlo en el núcleo, y le permite al administrador del sitio decidir qué módulo gestiona traducciones. También permite usarlo a los usuarios de la versión 1.0.x de Xaraya.

La clave es que sea simple. En mi mensaje anterior di algunas ideas, pero eran demasiado compejas y requieren un montón de código y proceso. Buscando cómo lo hacen otros CMS encontre algunos módulos para Wordpress que permiten la creación de contenido en varios lenguajes, como Polyglot (el que usamos en este blog), y la ide es tan simple que me enamoré . Usan unsa etiquetas con el formato < lang_xx >…< /lang_xx > o [ lang_xx ]…[ /lang_xx ], y muestran u ocultan el contenido basándose en la localización actual o en una variable get, todo en la misma área de texto, y también provee el código para mostrar una lista de banderas para ver el contenido existente en otros lenguajes presentes en el texto.

Hablando con MichelV pensamos que esto podía ser fácilmente hecho con código estandar (x)html, usando los atributos lang o xml:lang (para XHTML 1.1, que elimita el atributo lang de su DOCTYPE). Entonces, el módulo comprueba el contenido y lo muestra u oculta dependiendo de la localización actual del usuario y los atributos en el código. Solo debemos tener cuidado para no procesar las etiquetas con estos atributos que se encuentren anidadas (para dejara los editores crear código accesible y semántico). También podría implementarse fácilmente en editores WYSIWYG como TinyMCE.

Esto podría hacerse fácilmente con javascript y DOM, incluso con CSS, pero pienso que serí amejor hacerse en el lado del servidor (debido a la falta de soporte de DOM y selectores CSS en algunos navegadores), así que estoy probando con las clases DOM de PHP. Escribiré por aquí mis progresos con este módulo .

Acabo de terminar la traducción al español del paquete Core de Xaraya, y ya tengo bastante avanzada la traducción de una buena cantidad de módulos, sobre todo los más usados (Articles, xarBB, Categories, etc…)

Podeis descargar la traducción actual desde aqui (550Kb aprox) o desde monotone en breve, ya que se lo acabo de enviar a jojode.

Esperaba tener la página funcionando, al menos a un nivel básico, esta semana, pero he preferido tomarme otra semanita más para poder comprobar que lo que estoy haciendo cumple con mis espectativas, que suelen ser muy, muy exigentes . De momento he logrado simplificar la estructura del sitio bastante, pero quiero hacerlo aun más.

La idea básica es que el código sea lo más simple posible, y lograr que la página degrade bien incluso si se ve sin imágenes sin CSS (es decir, texto puro sin formato). Pero para lograr algunos de los efectos visuales del diseño es necesario añadir marcado que, si bien no altera la semántica, tampoco aporta nada, así que estoy pensando añadir este marcado mediante Javascript no intrusivo y DOM, usando una hoja CSS para versiones con javascript y otras para navegadores no compatibles más sencilla. De esta forma creo que mejoraré la accesibilidad del sitio, una de mis mayores preocupaciones en este momento.

Lo único malo de esto es que tengo que reescribir prácticamente todas las plantillas de Xaraya que utilizo para adecuar el código. De todas formas en un post posterior empezaré mi análisis sobre Xaraya con pequeñas cosas que me he ido encontrando y que podrían mejorarse.

Nos leemos.

I’ve read John Cox and Marcel’s posts and i’m very pleased to see that they think more or less about same thing as me, but I have some additional ideas.

Following John’s idea of using templates to manage all GUI functions and all my recent work to get a full MLS in Xaraya (for gui and content) I would like to propose a very radical idea: split off MLS, at least as we know it today. Yeah! I know, it sounds very radical, but i’ve very good reasons and solutions for all problems I’ve found, and i’ll try to show you how.

Localization of templates

First use of MLS is localization of interface into diferent languages, through xml files and blocklayouts tags.

Is well know that this paradigm slows down the whole system, and the only solution is delete all <xar:ml*>tags</xar:ml*> in templates and translate all strings, usually overriding module templates. But there is a problem. A lot of modules have diferent strings hardcoded in api or user functions, and if you want to have it translated you must use actual xml system.

But, if all display content is going to be rendered with templates, like John proposed, the need of a xml translation file is dead. All translations could be done directly in theme files. Now someone could see some problems:

It’s more work to translators!

No, it’s the same work, even best. My reasons are:

1. If you create a new theme, you must translate all new strings, and the only work you can reuse are modules and core templates translation (if you doesn’t customize it). If you override all module and core templates, you only need to do it once, and reuse in every theme you create.
2. Sometimes is hard to know the context of a translated string, and i think that it’s best to see it in context in order to create best translations.

How to handle more than one locale?

The system simply will load one or another theme depending of the language. It also allows an easy handle or rtl and ltr languages, as well complex sentences structure in languages like chinese, russian, etc…

And i see a lot of advantages:

• Speed boost: less code to work with and cache boost
• Cleaning of a lot of template tags
• Deleting of a core function, with a reduction of complexity in all system.

Localization of content

Ok, now we have deleted MLS from core, but what if we want to have a multilanguage site?. We need an optional MLS module that handles ML options (themes to call, locales avaliables, etc…). Althought it can also be defined in a config xml file

But we’re in the same place… ok, with a speed bost and a complexity reduction, but now we also need a bit more. We need the option to translate content for some modules.

I’ve thought of various options, but i think the best one is to allow it though new MLS module, adding, for example, a structure like <xar:mlvar>$var</xar:mlvar>. It could be done thanks to DD.

Each time a mode is hooked to MLS module, it creates a DD subform object with the same structure of the item it’s hooked. The only need is that the original module has a lang var (like articles).

When system find <xar:mlvar>$var</xar:mlvar> it check current user language and module and DD items, and have various options:

1. If item have translation in current locale, show it.
2. If item have not translation in current locale, doesn’t show it.
3. If item have not translation in current locale, show it in an avaliable locale, following an order defined in MLS module.

… I have a lot of other ideas, but now i have a great headache and i’ll leave it for the second post…

Pienso que cualquier tipo de mejora en usabilidad o accesibilidad que aportara sería superflua e inutil mientras el sistema no esté en mi lenguaje nativo. Es por ello por lo que estoy dedicando mi tiempo libre a esta labor.

Por suerte, el llamamiento que hemos hecho desde es.xaraya.com ha surtido efecto y ya hay varias personas interesadas en ayudar con la traducción. En una primera fase la idea es conseguir que la mayoría (si no todo) el sistema y los módulos más importantes estén traducidos. Más tarde, se crearía un grupo de “correctores” cuya labor sería la de supervisar que toda la traducción es consistente y correcta, aunque para ello se precisará también la ayuda de los usuarios, para lo que se abrirá seguramente un hilo en el foro de la página.

Bueno, os dejo para continuar con mi trabajo, aunque seguramente en estos días haga un pequeño análisis de la herramienta de traducción

Mi intención es dotar a este sistema, a mi gusto el más avanzado y flexible de los existentes actualmente de software libre, de una gran calidad en temas de usabilidad, accesibilidad o semántica.

Aunque una buena parte de esto es competencia directa del diseño que se haga para cada sitio web, espero ayudar a crear una base lo suficientemente sólida como para que cumpla con la mayor cantidad de reglas por defecto.

La estructura que seguiré no será periódica, sino que iré reflejando en este blog los avances que vaya haciendo y los resultados en la medida que pueda.

Además, cada artículo será monotemático, es decir, que trataré un solo tema en profundidad con sus problemas, posibles soluciones y justificaciones.

Por supuesto, siendo este un análisis totalmente abierto, y con la intención de mejorar un software libre, estoy totalmente abierto a la colaboración de cuantos quieran unirse al proyecto, ya sea usando los comentarios o creando una comunidad de bloggers sobre este tema.