Sobre traducciones y fallos que cuestan tiempo ...
Juan F. Ruiz - 22/03/2008
Hola, compañeros.


Os voy a hablar un poco de mi experiencia traduciendo de inglés a castellano una plantilla de Notes.

Primero miré en la documentación de Notes/Domino sobre las bases de datos multilingües y cómo configurar una base de datos para que soportara varios idiomas ... y la verdad, la forma que adoptaron para esto en Lotus/IBM no me gustó nada .... De cada objeto de diseño que soporte la funcionalidad de mostrarse en varios lenguajes ( formularios, subformularios, etc. ) debes hacer una copia  y a éstos cambiarles una propiedad que digan en el lenguaje en el que están. Luego traduces todas estas copias con el lenguaje indicado ... Con esto la base de datos se hace enorme y aparte, como no seas organizado, te puedes hacer un lío de narices, si tienes que tocar código, o enlazar algunos objetos a otros ...

Imaginad el resultado : un usuario inglés hace click sobre un documento en una vista en inglés y le aparece el documento con los nombres de los campos, las etiquetas y las instrucciones en castellano ...

Así que deseché esa opción y me puse a traducir directamente los objetos de diseño del inglés al castellano ... Y aquí empieza el trabajo de chinos de ver lo que se debe cambiar y lo que no ... aparte de empezar a pegarte con las entidades HTML ... Porque, al principio, no me dí cuenta de una propiedad muy importante de formularios y páginas .. y me lié a poner ñ donde había una 'ñ', á donde había una á ... y así ....

Luego descubrí que había bloques que no se mostraban, o se descolocaban los DIV's ... hasta que veía que se me había olvidado cerrar una comilla, etc...

Despues de unos días, llegué a un punto, donde algunas partes de la plantilla ( un blog ) parecían ser "intraducibles" ... me explico: si las traducía, la funcionalidad se iba al carajo, si lo dejaba en inglés todo iba bien ... Así que tuve que tocar código en algunos sitios. Por cierto, la funcionalidad de sindicación ( los RSS ) me dió mucha lata, ya que van en XML, y como el XML no esté validado .... así como algunas otras partes de la plantilla hasta que ví la luz ...

Navegando por las propiedades de un formulario, me di cuenta de que en la pestaña segunda ( La del gorrito ese raro ) hay un conjunto de propiedades que se aplican si se accede al formulario por web ... Una era "Content Type" que estaba fijada como "text/html" y luego otra cuyo nombre es "Character Set" ... ¡Dios! Si me hubiera dado cuenta de esta propiedad al principio no habría tenido tantos problemas ... Seleccioné "Unicode (UTF-8)" y todo empezó a funcionar como es debido ...

Os voy a dejar un pequeño código en @Fórmula que os permite convertir los caracteres latinos a sus correspondientes entidades HTML  :

listaLatin1:="á":"é":"í":"ó":"ú":"ñ":"Ñ":"Á":"É":"Í":"Ó":"Ú":"¿":"¡";
listaHtmlLatin1:="á":"é":"í":"ó":"ú":"ñ":
"Ñ":"Á":"É":"Í":"Ó":"Ú":"¿":"¡";
tmp:=@ReplaceSubstring(txtCampo;"&";"&");
FIELD txtHTMLCampo := @ReplaceSubstring(tmp;listaLatin1;listaHtmlLatin1);
@True

Este código lo colocaís en un botón, junto con dos campos de texto editables, uno de nombre "txtCampo" y el otro de nombre "txtHTMLCampo"  en un formulario y ya está.
1
Jose Eduardo Rios
24/03/2008 15:49:10

Tienes mucha razón Albert,

Hace un rato vi una base que baje desde OpenNTF que era multilenguaje, y este usaba un par de documentos con todas las palabras traducidas a distintos idiomas y con un proceso de actualización (agente) cambiaba el idioma.

Tambien en otra base (sino me equivoco una de conocimientos) que tambien probe de OpenNTF hacia algo parecido pero la dejaba demasiado pesada y se demoraba un resto en abrirse.

Aun no me he enfrentado a este tema (por suerte) de tener que crear un sistema multibilingüe.

Saludos

2
Juan Carlos Trigo Diaz
24/03/2008 18:52:22

Este tema ya lo pense para notesring hace mucho tiempo.

Yo no veo tanto problema para SLUG, porque somos muchos y no como en mi caso que era yo solo.

Yo no veo dificil hacerla de varios idiomas.

Lo unico son los contenidos, pero también depende del nivel que queramos dar a slug.

Si se tiene 1 articulo o 2 por día no será complicado.

Lo peor es tocar las plantillas de lotus, que llevan mucho tiempo.

Tendríamos que realizar una aplicación a medida, con las características. Por ejemplo un blog no sirve para publicar un manual, ni un foro.

Os paso algunas ideas.

Los textos fijos siempre pueden ser textos calculados con dblookups dependiendo del idioma.

O bien un formulario en castellano y otro en ingles y dependiendo del idioma se envia a una vista u a otra que abre el formulario del idioma correspondiente.

Realmente no es tanto trabajo si tenemos las ideas claras de que queremos publicar.

Otra cosa es traducir un manual que lleva bastante más trabajo. En aplicaciones como los foros es inviable, a no ser que se traduzca online, pero ya sabemos como va a traducir Notes, lotus o form, jejeje.

Un abrazo a todos

3
Albert Buendia
23/03/2008 11:52:11

Tienes toda la razón, Juan.

Uno se da cuenta lo que realmente cuesta una traducción cuando la aborda. Es importante que las plantillas y los códigos se parametrizen lo máximo posible para que en una librería de variables se pueda abordar una traducción con garantías. Últimamente he visto algunas plantillas muy bien hechas. Todo depende de cómo se programe.

Sólo hay que echar un vistazo al repositorio de Passport Advantage para darse cuenta de la complejidad y número de idiomas que tienen que enfrentarse los ingenieros y programadores de IBM: inglés, francés, español, alemán, finés, sueco, ruso.... y luego por la zona asiática..... japonés, chino, mandarín, etc........ Un galimatías nada fácil de resolver.

4
Fernando (SN)
27/03/2008 13:51:12

No se si veis que esta entrada descoloca el blog haciendo que tengamos que hacer uso del scroll para ver la parte derecha para los de resoluciones 1024 o inferiores.

Solo era eso.

Salu2.

Deja tu comentario

Sobre traducciones y fallos que cuestan tiempo ...