[opensuse-translation-es] Toy perdiooooooooooo
No acabo de entender en Verbum el estado de la traduccion. Puede ser un problema de las estadisticas. El caso es que aparecen marcados en rojo paquetes que ya estan traducidos. Alguien puede aclararme algo??? Es para saber por donde seguir. Un saludo Lluis
El 14/04/08, Lluis Martinez escribió:
No acabo de entender en Verbum el estado de la traduccion. Puede ser un problema de las estadisticas. El caso es que aparecen marcados en rojo paquetes que ya estan traducidos. Alguien puede aclararme algo??? Es para saber por donde seguir.
Tranqui. No es Verbum. No estamos en lo que llaman "string-freeze" (ni soft ni hard... ni plof ni fu) por lo que los desarrolladores siguen añadiendo mensajitos (parches nuevos) que tenemos que traducir... lo comentan por la lista general de traducción. Enga, ya has "descansao"... ahora a seguir trabajando (ar, ar, paso ligero...) :-P Saludos, -- Camaleón -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
On Mon, Apr 14, 2008 at 3:31 PM, Camaleón <noelamac@gmail.com> wrote:
No acabo de entender en Verbum el estado de la traduccion. Puede ser un problema de las estadisticas. El caso es que aparecen marcados en rojo paquetes que ya estan traducidos. Alguien puede aclararme algo??? Es para saber por donde seguir.
Tranqui. No es Verbum.
No estamos en lo que llaman "string-freeze" (ni soft ni hard... ni plof ni fu) por lo que los desarrolladores siguen añadiendo mensajitos (parches nuevos) que tenemos que traducir... lo comentan por la lista general de traducción.
Enga, ya has "descansao"... ahora a seguir trabajando (ar, ar, paso ligero...) :-P
Más allá de eso hay un problema con el script que actualiza las estadísticas (como podrán ver no se actualizan desde el 12/04). Espero corregirlo hoy ... pero gracias a los 'genios' de seguridad informática desde el trabajo no puedo acceder al administrador del sitio. -- Kind Regards
El 14/04/08, Gabriel escribió:
pero gracias a los 'genios' de seguridad informática desde el trabajo no puedo acceder al administrador del sitio.
Eh, eso quiere decir que hacen "bien" su trabajo ;-) Saludos, -- Camaleón -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Camaleón escribió: | El 14/04/08, Gabriel escribió: | |> pero gracias a los 'genios' de seguridad |> informática desde el trabajo no puedo acceder al administrador del |> sitio. | | Eh, eso quiere decir que hacen "bien" su trabajo ;-) | Jeje, si tan sólo los conocieras .... Respecto a las stats, ya deberían estar actualizadas. Aunque en este momento aún lleva corriendo 50' y la fecha no se actualiza hasta el final, los archivos de 'español' ya se actualizaron. Saludos. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFIA+AXNHr4BkRe3pIRCIQQAJ9ZHqM1koM91Cu5hmLck+tExXEo5ACePw3a eUgB87o/YXzMPIfmR0sJuYo= =O1bo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-04-14 a las 19:52 -0300, Gabriel escribió:
Respecto a las stats, ya deberían estar actualizadas. Aunque en este momento aún lleva corriendo 50' y la fecha no se actualiza hasta el final, los archivos de 'español' ya se actualizaron.
Se me ocurre... ¿sería posible actualizar los datos de un fichero cuando se cambia su estatus? En traducción hecha, en revisión hecha, y en commit. Es decir, en vez de recalcular todo, recalcular los cambios. Igual se puede hacer con rapidez. O igual no, porque son un montón de ficheros y muchos traductores. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIA+cltTMYHG2NR9URAo6PAJ92sYzpFrH8YHH+Irb7RoVIA7MH1wCdGJjp pR4mRUdErHeDBaU57OLySxw= =uQsb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Carlos E. R. escribió: | | | El 2008-04-14 a las 19:52 -0300, Gabriel escribió: | |> Respecto a las stats, ya deberían estar actualizadas. |> Aunque en este momento aún lleva corriendo 50' y la fecha no se |> actualiza hasta el final, los archivos de 'español' ya se actualizaron. | | Se me ocurre... ¿sería posible actualizar los datos de un fichero cuando | se cambia su estatus? En traducción hecha, en revisión hecha, y en | commit. Es decir, en vez de recalcular todo, recalcular los cambios. | Igual se puede hacer con rapidez. O igual no, porque son un montón de | ficheros y muchos traductores. | Se me había ocurrido, pero haría el cambio de estado algo lento, ya que hay que descargar el archivo y procesarlo. Y si hay muchas modificaciones puede ser molesto. Lo que puedo hacer es un queuee que corra digamos cada 30', eso sí sería factible. Saludos. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFIA++4NHr4BkRe3pIRCIRaAKCSbFzvT6wBH20ue7oXCXixYKLwyACgvtD1 4hgCB/6L4YkvDcxZfeM2j8s= =hhjG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-04-14 a las 20:58 -0300, Gabriel escribió:
| Se me ocurre... ¿sería posible actualizar los datos de un fichero cuando | se cambia su estatus? En traducción hecha, en revisión hecha, y en | commit. Es decir, en vez de recalcular todo, recalcular los cambios. | Igual se puede hacer con rapidez. O igual no, porque son un montón de | ficheros y muchos traductores. |
Se me había ocurrido, pero haría el cambio de estado algo lento, ya que hay que descargar el archivo y procesarlo. Y si hay muchas modificaciones puede ser molesto. Lo que puedo hacer es un queuee que corra digamos cada 30', eso sí sería factible.
Otra idea, que no se si es lo que estás pensando. En vez de procesarlo antes de actualizar la página, guardas la referencia de ese fichero en una cola, y un proceso lento y tranquilo (en modo nice o en batch) va leyendo esa lista y procesandola, actualizando las estadisticas si hay diferencias. Otra posibilidad es hacer un "svn up" cada media hora, apuntando todos los ficheros que cambian, y procesando esos, o añadiendolos a la lista de antes. La ventaja de combinar ambos metodos es estar seguro de cazar todos los cambios: los que originan los traductores y los que no, y los cambios que se suben sin decirselo al Verbum. Tienes un montón de posibilidades para entretenerte ;-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIA/cBtTMYHG2NR9URAmRIAJ983CXosJ/kMhcRgyWXSH92vA/U5QCeL/V2 ny3/NZkalJEVfXil0O1TUng= =3jWm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Carlos E. R. escribió: | Otra idea, que no se si es lo que estás pensando. En vez de procesarlo | antes de actualizar la página, guardas la referencia de ese fichero en | una cola, y un proceso lento y tranquilo (en modo nice o en batch) va | leyendo esa lista y procesandola, actualizando las estadisticas si hay | diferencias. Sip, es lo que tengo en mente. | | Otra posibilidad es hacer un "svn up" cada media hora, apuntando todos | los ficheros que cambian, y procesando esos, o añadiendolos a la lista | de antes. La ventaja de combinar ambos metodos es estar seguro de cazar | todos los cambios: los que originan los traductores y los que no, y los | cambios que se suben sin decirselo al Verbum. Aquí no es viable, ya que no por cuestiones de certificados y acceso https no puedo hacer funcionar el svn en el host (y por otro lado el espacio, ya que son varios equipos y llega a ocupar bastante) El método de actualización es descargar cada archivo usando http y luego aplicar el msgfmt sobre el archivo para procesar las stats. | | Tienes un montón de posibilidades para entretenerte ;-) | Creo que con la cola de archivos modificados corriendo cada 30' y el batch actual cada 12 hs sería suficiente para mantenerlo regularmente actualizado. Saludos. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFIA/soNHr4BkRe3pIRCOfBAKCquK/WcWQi06qFh/0zzwimgKVwywCfUaGL rmcMr2coqjM8LgOBFigU3sg= =4THF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.1.00.0804150343150.13653@nimrodel.valinor> El 2008-04-14 a las 21:47 -0300, Gabriel escribió:
Carlos E. R. escribió: | Otra idea, que no se si es lo que estás pensando. En vez de procesarlo | antes de actualizar la página, guardas la referencia de ese fichero en | una cola, y un proceso lento y tranquilo (en modo nice o en batch) va | leyendo esa lista y procesandola, actualizando las estadisticas si hay | diferencias.
Sip, es lo que tengo en mente.
Ah, vale.
| Otra posibilidad es hacer un "svn up" cada media hora, apuntando todos | los ficheros que cambian, y procesando esos, o añadiendolos a la lista | de antes. La ventaja de combinar ambos metodos es estar seguro de cazar | todos los cambios: los que originan los traductores y los que no, y los | cambios que se suben sin decirselo al Verbum.
Aquí no es viable, ya que no por cuestiones de certificados y acceso https no puedo hacer funcionar el svn en el host
¿No? Vaya, pues es una pena.
(y por otro lado el espacio, ya que son varios equipos y llega a ocupar bastante)
¿Varios equipos? Ah, vale, equipo =/= host, sino "teams". Son los directorios "po" de cada equipo. Contando los memory y pot, son medio giga. Pero sólo los "po" son una docena de megas a lo sumo, *2 (lcn y yast), son 25 megas por arriba.
El método de actualización es descargar cada archivo usando http
Ah. Eso es bastante pesado, porque tendrás que bajar todos los ficheros uno a uno aunque no haga falta... Entiendo porqué tarda tiempo, entonces. ¿Has probado wget? Puede clonar directorios web.
y luego aplicar el msgfmt sobre el archivo para procesar las stats.
Ya... ¿Y no es posible intentar echar a andar el svn? Debería poderse. Eso sí que es una pena.
| | Tienes un montón de posibilidades para entretenerte ;-) |
Creo que con la cola de archivos modificados corriendo cada 30' y el batch actual cada 12 hs sería suficiente para mantenerlo regularmente actualizado.
Si no satura el procesador, sí. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIBAhrtTMYHG2NR9URAvuOAJ98S/pgQFoKRmzU1U3KB4scSnvLvACeI3C9 T9dW+V1ZqQi1JJbtdore6kY= =Bvz1 -----END PGP SIGNATURE-----
2008/4/14 Carlos E. R. <robin.listas@telefonica.net>:
¿Varios equipos? Ah, vale, equipo =/= host, sino "teams". Son los directorios "po" de cada equipo. Contando los memory y pot, son medio giga. Pero sólo los "po" son una docena de megas a lo sumo, *2 (lcn y yast), son 25 megas por arriba.
Claro, calcula que actualmente hay unos 10 teams usando la aplicación.
Ah. Eso es bastante pesado, porque tendrás que bajar todos los ficheros uno a uno aunque no haga falta... Entiendo porqué tarda tiempo, entonces.
¿Has probado wget? Puede clonar directorios web.
Es que no es tan simple, para bajar uso la interfaz web del svn, con un cliente para php bastante útil, pero para usar wget tengo que conocer el número de revisión para obtener el último archivo y termino haciendo más trabajo.
¿Y no es posible intentar echar a andar el svn? Debería poderse. Eso sí que es una pena.
Pues así era mi primera opción, pero al subirlo al hosting se complicó porque el svn no tiene un opción para forzar aceptar el certificado y el svn de novell sólo tiene acceso por https (aunque sea anónimo). Por otro lado, el proceso igual no traería ventaja, ya que por cuestiones de espacio tendría que hacer continuamente checkouts (no updates) porque tendría que ir eliminando por cada team. Sólo cuento con 50mb en el hosting. Y el método actual baja uno, borra, y así sucesivamente :-D Demora unos 50' en procesar todos los equipos actuales.
| | Tienes un montón de posibilidades para entretenerte ;-) | Creo que con la cola de archivos modificados corriendo cada 30' y el batch actual cada 12 hs sería suficiente para mantenerlo regularmente actualizado.
Si no satura el procesador, sí.
Y el ancho de banda :-D -- Kind Regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-04-15 a las 10:01 -0300, Gabriel escribió:
2008/4/14 Carlos E. R. <>:
Claro, calcula que actualmente hay unos 10 teams usando la aplicación.
Ah. Eso es bastante pesado, porque tendrás que bajar todos los ficheros uno a uno aunque no haga falta... Entiendo porqué tarda tiempo, entonces.
¿Has probado wget? Puede clonar directorios web.
Es que no es tan simple, para bajar uso la interfaz web del svn, con un cliente para php bastante útil, pero para usar wget tengo que conocer el número de revisión para obtener el último archivo y termino haciendo más trabajo.
Ah, vale.
¿Y no es posible intentar echar a andar el svn? Debería poderse. Eso sí que es una pena.
Pues así era mi primera opción, pero al subirlo al hosting se complicó porque el svn no tiene un opción para forzar aceptar el certificado y el svn de novell sólo tiene acceso por https (aunque sea anónimo).
Me aprece que te dije algo de simularlo en otro equipo en el que sí tuviera consola, y luego subirlos ficheros con la aceptación aceptada al hosting.
Por otro lado, el proceso igual no traería ventaja, ya que por cuestiones de espacio tendría que hacer continuamente checkouts (no updates) porque tendría que ir eliminando por cada team. Sólo cuento con 50mb en el hosting. Y el método actual baja uno, borra, y así sucesivamente :-D Demora unos 50' en procesar todos los equipos actuales.
Esto he tardado una comida en masticarlo y darme cuenta. ¡No tienes sitio para guardar todos los pos! Lo que haces es bajar uno, mirarlo, contarlo, borrarlo, y bajar el siguiente, ¿no? Tienes que bajar todos y borrar todos. ¡JUPE! Claro, no tienes otro remedio, no caben. Si cupieran, entonces un "svn up" sería lo ideal, porque sólo baja los cambios.
| | Tienes un montón de posibilidades para entretenerte ;-) | Creo que con la cola de archivos modificados corriendo cada 30' y el batch actual cada 12 hs sería suficiente para mantenerlo regularmente actualizado.
Si no satura el procesador, sí.
Y el ancho de banda :-D
Otra posibilidad: procesado distribuido. Metes un script en uno o varios ordenadores de cada equipo, en su cron,los cuales mandan un correo formateado al Verbum, que se usa para actualizar las estadísticas. :-P En plan "proyecto ..." vaya, se me ha ido el nombre. Ese proyecto que busca ondas de radio extraterrestres, que se procesa en multitud de ordenadores de voluntarios. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIBPRwtTMYHG2NR9URAjHXAJ9wd+QIpQUWzUUa5+sOA1K5uoHMXACfSqKb R4l1gJq+fnBma89ZUMQ8Lw0= =hddx -----END PGP SIGNATURE-----
2008/4/15 Carlos E. R. <robin.listas@telefonica.net>:
Pues así era mi primera opción, pero al subirlo al hosting se complicó porque el svn no tiene un opción para forzar aceptar el certificado y el svn de novell sólo tiene acceso por https (aunque sea anónimo).
Me aprece que te dije algo de simularlo en otro equipo en el que sí tuviera consola, y luego subirlos ficheros con la aceptación aceptada al hosting.
Es posible, pero igual lo descarte por motivos de espacio.
Esto he tardado una comida en masticarlo y darme cuenta. ¡No tienes sitio para guardar todos los pos! Lo que haces es bajar uno, mirarlo, contarlo, borrarlo, y bajar el siguiente, ¿no? Tienes que bajar todos y borrar todos. ¡JUPE! Claro, no tienes otro remedio, no caben.
Si cupieran, entonces un "svn up" sería lo ideal, porque sólo baja los cambios.
Exactamente.
Otra posibilidad: procesado distribuido. Metes un script en uno o varios ordenadores de cada equipo, en su cron,los cuales mandan un correo formateado al Verbum, que se usa para actualizar las estadísticas.
:-P
En plan "proyecto ..." vaya, se me ha ido el nombre. Ese proyecto que busca ondas de radio extraterrestres, que se procesa en multitud de ordenadores de voluntarios.
Esta opción estaría interesante. El tema también por el cual no actualizo más frecuente es para no saturar el svn. Voy a ponerme a investigar un poco más, si puedo obtener más información del archivo, puedo detectar si fue modificado y en ese caso descargarlo, y caso contrario sigo con el siguiente. -- Kind Regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-04-14 a las 21:09 +0200, Camaleón escribió:
El 14/04/08, Gabriel escribió:
pero gracias a los 'genios' de seguridad informática desde el trabajo no puedo acceder al administrador del sitio.
Eh, eso quiere decir que hacen "bien" su trabajo ;-)
No es lo mismo no poder salir que no poder entrar >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIA+ZTtTMYHG2NR9URAltVAJ0TGvBn293Zo+4LOvhGxHZDw/uXvwCgl6b+ HnlcD0nfJN1sddnFKOD04lo= =nrM+ -----END PGP SIGNATURE-----
participants (4)
-
Camaleón -
Carlos E. R. -
Gabriel -
Lluis Martinez