- kune-devel - lists.ourproject.org

Sobre Kune y GPLv3
by Vicente Jos Ruiz Jurado 10 Aug '07

10 Aug '07

Muy buenas queridos: Estabamos usando la GPLv2 para kune pero estamos pensando usar la GPLv3. Estaba leyendo esto: http://www.gnu.org/licenses/rms-why-gplv3.html Este es nuestro fichero de copyright actual: http://ourproject.org/plugins/scmsvn/viewcvs.php/trunk/COPYRIGHT?rev=48&roo… Luego metemos la licencia resumida en cada fuente. ¿Se os ocurre algún comentario al respecto de empezar a usar la GPLv3? No se, estoy pensando demasiado en código y no me queda cabeza para estas cosas. Abrazos y muchas gracias por anticipado, espero que estéis muy bien, Vicente

3 2

Traducción de kune, de documentos y propuesta de organización
by Vicente J. Ruiz Jurado 28 Jun '07

28 Jun '07

Buenassss: Bueno, he estado pensando y mirando mucho estos días sobre el tema de las traducciones (por ponerle un título). En fin, voy a hacer un resumen. Lo que me molaría es a grandes rasgos: a) que kune se pueda traducir como aplicación de forma fácil (vía web). b) que la gente pueda traducir documentos o contenidos a otros idiomas (tb claro vía web). c) permitir también traducir campos de nuestro repo o bd, que va a ser necesario tarde o temprano. La idea es usar para a/b/c el mismo procedimiento de traducción. Globalize de rails hace bastante fácil a/c y el procedimiento es relativamente sencillo. Adjunto attach de cuando estaba haciendo pruebas con rails, como quedaba la pantalla de traducción. Je je... casi me molaba más el aspecto que tenía antes todo esto... en aquel momento mi duda era que era lo que le faltaba a globalize para permitir traducir del mismo modo documentos. Globalize ya viene con muchas cadenas comunes traducidas (como meses, días de la semana, etc) que podemos reusar. Así que he estado mirando herramientas de traducción de documentos más o menos profesionales, de documentos, de aplicaciones, y como se lo montan. Más allá de que hay formatos estándares para tratar la información, para reusar traducciones ya hechas, para sugerir traducciones, el interfaz de usuario es bastante sencillo. Se divide (segmentación) el documento en partes (segmentos) mediante expresiones regulares (que podemos reusar), y se permite la traducción de cada uno de los segmentos del documento. Una vez traducido se une de nuevo. Una captura de un software web para traducir software libre: http://info.linspire.com/irma/ y otra de un traductor de documentos por segmentos: https://open-language-tools.dev.java.net/editor/screenshot.png para así visualizar lo que estoy comentando. He pensando un repositorio con una propuesta de pinta como esta (las propiedades terminan en -p): repo `-- cms `-- folders |-- documents | |-- group-p # grupo al que pertenece | |-- languageBase-p | |-- permissions-p | |-- segments | | |-- commentToTranslators-p | | |-- originalContent-p | | `-- translations | | |-- contentTranslated-p | | |-- isTheCurrentTranslation-p | | |-- language-p | | `-- needsRevision-p | |-- title-p | `-- user-p # usuario al que pertenece |-- group-p # grupo al que pertenece |-- languageBase-p |-- permissions-p |-- title-p |-- translations | |-- contentTranslated-p | `-- language-p `-- user-p # usuario al que pertenece y que intenta reflejar lo que he visto estos días: que un documento tiene uno o varios segmentos, que de un mismo segmento puedo haber varias traducciones, e incluso varias traducciones en un mismo idioma del cual se elige solo una de ellas (esto se podría simplificar quizá con el versioning), y que algunas traducciones, no están finas todavía. El tema de propietarios/permisos está muy poco pensando, pero lo he puesto igualmente. En realidad, creo que se debería pensar como en Unix y que fichero y directorio, fuera lo mismo, pero vamos, lo he separado por aclarar un poco. Además pienso que el título de ficheros/carpetas debería ser el primer segmento (así también es traducible) pero bueno, lo he dejado así por aclarar. Quedaría así (he quitado folder y he metido la propiedad type): repo `-- cms `-- file |-- languageBase-p |-- segments | |-- originalContent-p | |-- commentToTranslators-p | `-- translations | |-- contentTranslated-p | |-- isTheCurrentTranslation-p | |-- language-p | `-- needsRevision-p |-- type-p # dir o doc |-- permissions-pequipo |-- group-p `-- user-p El uso de directorios ya lo justificaré en otro correo que tengo medio escrito más adelante ;) La idea es crear una estructura de repo, que permita desarrollar estas cosas en el futuro, y no quedarnos muy limitados desde el principio. A lo práctico, los apartados de antes quedarían así: a) Imaginemos un properties de Java, cada propiedad sería un segmento. Con todas las traducciones se generan (con un programa de utilidad) los diferentes properties de cada lenguaje (de GWT o del Server o de lo que sea) y se usa en tiempo de compilación. Muy contado a grosso modo. b) Se crea un documento en un lenguaje determinado, y se salva en segmentos, lo cual no dará curro pero nos permitirá muchas cosas: manejar en un futuro una edición colaborativa y el bloqueo de segmentos no del todo el documento, editar y paginar con comodidad documentos grandes, y a lo que vamos, la traducción por segmentos. Creo que esta estructura permitiría incluso la localización sencilla de imágenes (con textos claro). c) Los campos de BD (o de objetos o como lo queramos ver): Imaginemos que tengo en la bd(o repo) una licencia, y el campo nombre de licencia es traducible "Creative Commons Share-Alike" --> "Creative Commons Comparte por Igual". Pues en la bd/repo, esta en el idioma original (ingles), pero igual con un interceptor (jeje), según el locale de la sesión actual devolvemos la cadena traducida que extraemos del repo, no la versión inglesa. En Globalize de rails, al programar se usaban cadenas del tipo: "Login to collaborate".t y ya con eso, se encargaba de ver en tiempo de ejecución si estaba traducido en la bd para ese locale actual, y si no devolvía la misma cadena en inglés. He estado pensando que se podría hacer algo parecido con GWT, pero no me mola mucho por el momento. Para ello se puede usar ConstantsLookup en vez de Constants y hacer llamadas del tipo: Trans.getString("Login to collaborate"), que o consigue la constante compilada o si no la encuentra intenta acceder o hacer alguna operación en el servidor, mientras devuelve la cadena en ingles (parecido a globalize). Pero bueno, esto no me emociona del todo por ahora. En fin, esto es en lo que estoy pensando ahora. Hay todavía cosas por definir, como los plurales, pero creo que se puede usar la experiencia de globalize y otros proyectos. Creo que una estructura de repo que incluya de alguna forma estas cosas, puede hacer que la parte más usada de kune, la edición/visualización de contenidos sea lo suficientemente potente/útil como para que se use a saco, que era lo que hablábamos hace unas semanas danigb y yo. Por otro lado he preguntando a Antonio por alguna persona que pudiese "liderar" esta parte (la definición y más adelante coordinar los traductores) del grupo del FSM que se encarga de las traducciones (babels). Esto es solo una propuesta muy inicial de como atacar el tema de ficheros/folders y sus traducciones. Con lo que hablemos, meteré el resultado en el wiki para que este correo no se pierda en el limbo de nuestros correos. Abrazos, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Al principio creí que estaba luchando por salvar los árboles. Después pensé que estaba luchando por salvar la selva amazónica. Ahora me doy cuenta de que estoy luchando por la humanidad." [Chico Méndez]

1 0

[kune] PUBLICADO: Propuestas de aspecto futuro de kune en el FSM
by noreply＠ourproject.org 01 Jun '07

01 Jun '07

Artículo publicado ------------------- El artículo "Propuestas de aspecto futuro de kune en el FSM" ha sido validado por Vicente J. Ruiz Jurado. ** Propuestas de aspecto futuro de kune en el FSM ** el Viernes 1ro de junio de 2007 Mostramos aquí una serie de esbozos orientativos de lo que podría ser kune adaptado para el FSM una vez completado el desarrollo y puesta en funcionamiento. Se muestra unas capturas de lo que sería un navegador web en una pantalla de resolución pequeña (800x600 pixels): Página inicial de una organización Esta sería la página inicial de una organización registrado en el FSM: Página inicial de un usuario/a Página inicial de un usuario/a que participa en varios grupos, su red de contactos, y sus contenidos públicos. Salas de charla de una organización Una de las salas de charla de una organización en la que intervienen tres personas: Miembros de una organización (red social) Esta sería la página en la (...) -> http://kune.ourproject.org/spip.php?action=redirect&id_article=6

1 0

Primeras capturas del futuro Interfaz de Usuario de kune
by Vicente J. Ruiz Jurado 03 Apr '07

03 Apr '07

Muy buenas: Ayer empecé a hacer un poco el interfaz de usuario (con el Google Web Toolkit) en plan algo más definitivo. Todavía no las he terminado, pero así voy: http://img144.imageshack.us/my.php?image=main1175300876719fd7.png http://img301.imageshack.us/my.php?image=main1175301071826vg8.png esta última en árabe, es para probar como van las cosas con carácteres no latinos. Esto ya no son dibujos, son páginas web reales ;) que se conectarán en el futuro con el servidor (el resto de la arquitectura). Lo que se ha hecho más evidente estos días para mi, es que hay que hacer unos bocetos (quizá solo uno completo) más refinados de lo que sería el interfaz de usuario. Los anteriores han estado muy bien para consensuar, para hacernos una primera idea, pero ahora hay que hilar fino. Es ahora cuando estoy viendo que debería hacer scroll en la página, que no, etc. Me preocupa por ejemplo el hecho de tener charlas abiertas en salas, y estar editando o buscando algún documento. Se podría solucionar de una forma similar a como lo hace gmail (ventanitas flotantes para las chalas abiertas, o ventanas adicionales del navegador). Y me ha venido a la cabeza una y otra vez, el comentario de danigb sobre el "dashboad", cito: para discutir - espacio personal: después de hablar con Vicente y Dani y darle unas cuántas vueltas no estoy muy seguro de que cada persona tenga un espacio propio donde publicar... es decir, creo que debemos fomentar el trabajo en grupo... a mi me parece útil que cada persona tenga un "lugar" donde puede administrar su trabajo dentro de distintos proyectos de manera unificada, es decir, un sitio donde pueda ver, por ejemplo, qué ha editado, quiénes han respondido a sus dudas, qué proyectos en los que participa o está interesado están activos... es decir, lo que se suele llamar un dashboard. No creo que tenga mucho sentido publicar una entrada fuera del contexto de un proyecto-colectivo. Si es ese el caso, creo que no es el sitio para publicarla... es decir: a mi esto no me parece una herramienta personal (léase blog o similares), sino colectiva, y creo que fomentar esa colectividad debería ser objetivo de kune... aunque no se me escapa que dentro de esta sociedad tan individualista, el tener un lugar propio (aunque dentro de kune) donde expresarse es muy atractiva... -Danigb 27/02/07 18:39 Lo único que no lo veo todavía del todo gráficamente. Me interesa la idea de espacio de trabajo personal muy claro, dentro de la ventana, pero discrepo en que no haya un espacio de visibilidad personal (desde el exterior), porque nos guste o no es algo que mueve montañas. En definitiva, que estoy pensando como ubicar dentro de unos bocetos más definitivos, el estado del trabajo/interacción del usuario actual (que charlas tiene abiertas, etc), sin complicar/recargar mucho la ventana. El objetivo de este correo es para pedir más comentarios, ideas, etc, si os apetece para refinar lo que será el interfaz de usuario. Abrazotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Tenemos un país donde un presidente ficticio nos lleva a una guerra ficticia por razones ficticias. Presidente Bush, usted es una vergüenza. Y se va a quedar solo." [Michael Moore al recibir el Oscar por "Bowling for Columbine"]

2 2

Erre que erre con la edición colaborativa...
by Vicente J. Ruiz Jurado 28 Mar '07

28 Mar '07

Muy buenas: Yo sigo pesado (fantaseando?) con lo de mejorar el wiki, con lo de la edición colaborativa en kune, con lo de dejar de usar docs.google para el desarrollo etc, etc. He encontrado esto (en fase de desarrollo, pero prometedor): http://synchroedit.com/ es una "beta". Me he creado una cuenta y he estado probando y mmm, tiene muy buena pinta. Encima tiene un parche para mediawiki. Lo he estado probando en una instalación local y promete también. Captura de mi navegador con mi instalación: http://img144.imageshack.us/my.php?image=capturafirefox2xy1.png No me funciona todo perfectamente, pero la verdad que tiene pinta de ser algo serio. Ah, el servidor está escrito en java :P En fin, seguimos mirando... Abrazotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Qué sería de la vida, si no tuviéramos el valor de intentar algo nuevo" [Vincent van Gogh]

1 0

svn, svgs, y otras imágenes
by Vicente J. Ruiz Jurado 26 Mar '07

26 Mar '07

Muy buenas: He activado el svn de kune y he empezado a meter las imágenes, luego me he liado con los copyrights y otros ficheros varios. Por ahora tenemos acceso DaniJ y yo, así que DaniG si quieres tener acceso, create una cuenta en ourproject.org y te añado al proyecto. Las instrucciones del svn están aquí: http://ourproject.org/scm/?group_id=407 He hecho una versión de la arquitectura en plan vectorial, y la he metido en docs.google y tb he subido el svg. Para modificar los svgs, como no es código, mejor ir avisando en plan: "quiero modificar tal fichero" y así no nos solapamos (si se os ocurre alguna forma mejor porque el whiteboard de inkscape todavía no funciona en todas las plataformas...). He creado un poco la estructura, y unos ficheros tipo (changelog, COPYRIGHT, etc). En el COPYRIGHT le he puesto una estructura para incluir licencias de todo lo que usemos que no sea nuestro. En cuanto a las licencias nuestras, las clásicas. Si algo no os gusta, modificarlo. Comentarios, hurras y abucheos, bienvenidos. Abrazos, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "No camines detrás de mí, puedo no guiarte. No andes delante de mi, puedo no seguirte. Simplemente camina a mi lado y sé mi amigo." [Albert Camus]

1 0

Probando wikis: xwiki
by Vicente J. Ruiz Jurado 16 Mar '07

16 Mar '07

Muy buenas: Intentando meter un WYSIWYG a nuestro mediawiki he estado probando un montón de wikis porque no me convencía los parches al mediawiki. Para comparar: http://www.wikimatrix.org Lo que más me ha gustado es xwiki, un wiki de segunda generación, según se autodenominan, y creo que tiene cosas interesantes y que hemos hablado estos días Dani y yo. También tiene errores de usabilidad gordos...creo que nuestro camino está por ahí pero ganando en usabilidad y en sencillez. http://www.xwiki.org Dani, tb te interesará si estabas buscando un wiki WYSIWYG como me contabas en Madrid. Está escrito en java y yo lo he instalado localmente para probarlo. Cosas que me gustan así rápido: - La mezcla de blog y editor - Las páginas son publicas y editables por defecto, te lo tienes que currar para lo contrario. - Lo mismo con las licencias - La forma de crear páginas - El editor - Añadir comentarios y attachments más o menos fácilmente - Parece que se puede añadir un montón de cosas más Lo que no me gusta: - Los ACLs freekies - A veces no salva bien - El UTF8 funciona regular (es una beta) - Las cosas raras, terminología y funcionalidad que no entiende la peña (permanent links, spaces, etc, etc) También me he estado pensando quitar el mediawiki de kune y meter xwiki (aunque es una versión beta), ya nos decidiremos. Vaya día aburridote de pruebas, con lo chulo que estuvo ayer dale que te pego con el Dani... Nada mas, besotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Great effort from great motives is the best definition of a happy life." [William Ellery Channing]

1 0

[kune] PUBLICADO: Principios del FSM y Kune
by noreply＠ourproject.org 08 Feb '07

08 Feb '07

Artículo publicado ------------------- El artículo "Principios del FSM y Kune" ha sido validado por Vicente J. Ruiz Jurado. ** Principios del FSM y Kune ** por dani71 el Jueves 8 de febrero de 2007 Hemos destacado de los principios del FSM aquellas partes que tener relación con una herramienta colaborativa de trabajo en red como es (será) Kune. Los principios están tomados de la [http://www.forumsocialmundial.org.br/main.php?id_menu=4&cd_language=4 Carta de Principios del Foro Social Mundial]. 1. El Foro Social Mundial es un espacio abierto de encuentro para: intensificar la reflexión, realizar un debate democrático de ideas, elaborar propuestas, establecer un libre intercambio de experiencias y articular acciones eficaces por parte de las entidades y los movimientos de la sociedad civil que se opongan al neoliberalismo y al dominio del mundo por el capital o por cualquier forma de (...) -> http://kune.ourproject.org/spip.php?action=redirect&id_article=5

1 0

[kune] Propuesto: Principios FSM y KUNE
by noreply＠ourproject.org 08 Feb '07

08 Feb '07

Artículo propuesto ------------------ El artículo "Principios FSM y KUNE" fue propuesto para ser publicado. Estás invitado/a a consultarlo y a dar tu opinión en el foro que le concierne. Está disponible en la dirección: http://kune.ourproject.org/ecrire/?exec=articles&id_article=5 ** Principios FSM y KUNE ** por dani71 Hemos destacado de los principios de FSM aquellas partes que tener relación con una herramienta colaborativa de trabajo en red como es (será) Kune. Lor principios están tomados de: http://www.forumsocialmundial.org.br/main.php?id_menu=4&cd_language=4 1. El Foro Social Mundial es un espacio abierto de encuentro para: intensificar la reflexión, realizar un debate democrático de ideas, elaborar propuestas, establecer un libre intercambio de experiencias y articular acciones eficaces por parte de las entidades y los movimientos de la sociedad civil que se opongan al neoliberalismo y al dominio del mundo por el capital o por cualquier forma de imperialismo y, también, empeñados en la construcción (...)

1 0