Traducir las validaciones

[PalumboN]

Ahora las validaciones vienen con un código de error, luego el mensaje se arma por idioma.

• Los códigos de errores se pueden ver en el validador
• Estaría bueno que las traducciones se puedan reutilizar desde otros proyectos como el IDE. Hablar con @fdodino sobre cómo hacer esto.

[fdodino]

Hola @PalumboN,
la traducción a lenguaje ya está pensada, solo hay que hacer el laburo de escribir los mensajes de error en base a lo que tenemos de Wollok Xtext, (también en español) y ver de paso si hace falta agregar información en los nodos. Es una de las cosas que quedan pendientes con prioridad.
Abrazo!
Fer

[PalumboN]

Hola @fdodino

Sí exacto, y quizá podamos dar una mano con eso. Pero lo que queremos es reutilizar las traducciones en mobile también (y más lugares).

Estaba pensando si no conviene tenerlas en Wollok-TS.

[fdodino]

Acá lo llamo a @nscarcella que era bastante reticente a hacer eso.

No se si hay algún motivo para no usar el proyecto del IDE, pero me suena a que vas a querer varias cosas del wollok-lsp-ide (ex-linter) a futuro. Hoy es el mensaje de error, mañana puede ser el formatter, o el autocompletado... Y no debería ser muy pesado.

[PalumboN]

Sí, seguro vamos a querer compartir varias cosas (nosotros ya tenemos un autocompletado ;) ), por eso no quiero que estén ni en mobile ni en el IDE. Si no queremos engordar TS podría ser (un) proyecto(s) aparte(s), como hicimos estamos haciendo con Wollok-Game-Web, que lo sacamos del cliente web para poder usarlo también desde los IDEs.

[fdodino]

Y está bueno tener tantos proyectos separados? Entiendo y compro totalmente disociar

• wollok-language
• wollok-ts
• wollok-mobile
• wollok-lsp-ide
• wollok-game-web

Pero tener tanta granularidad me parece que nos va a complicar porque además hay una dependencia de componentes para no repetir lo que ya está hecho.

[nscarcella]

Yo sigo pensando que definir el string concreto que ve el usuario en su idioma es un problema de frontend y mantendría esa responsabilidad separada del backend del lenguaje. Primero porque no creo que querramos hacer un deploy y un incremento de versión cada vez que querés frasear algo distinto en alguna de las plataformas (o romper inadvertidamente la vista de una que no estás teniendo en cuenta) y segundo porque no estoy convencido de que quieras usar los mismos textos y herramientas de traducción en todos lados (no sé, las dimensiones del celular y del IDE son muy distintos y probablemente el uso difiera y requiera comunicaciones distintas o textos que son especificos de uno o el otro, por ejemplo, textos con links a partes de la aplicación).

Entiendo lo incomodo de tener multiples proyectos, pero si quieren compartir traducciones me parece más sano tenerlas en otro lugar.

Por otro lado entiendo que el fraseo de un error es un aspecto al que uno quiere prestarle atención desde un punto de vista didáctico y dejar que cada implementación lo defina por separado podría ser medio choto.

Tal vez, mientras no sean textos especificos de una plataforma en particular podemos ponerlo en Language... De todas las alternativas creo que esa es la que mantiene lo mejor de ambos mundos.

[PalumboN]

Sí, igual tenerlas en Language también implicaría deployar Wollok-TS, no? Porque yo me imagino accediendo ahí a través de Wollok TS 🤔

Yo voto por tener un wollok-tools con todo lo referido a toolings que queramos compartir entre proyectos, separado del core del lenguaje