-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexandro Colorado escribió: > On Fri, 12 Oct 2007 14:28:26 -0500, Oscar Manuel Gómez Senovilla > <[EMAIL PROTECTED]> wrote: > > Alexandro Colorado escribió: >>>> On 10/12/07, Oscar Manuel Gómez Senovilla <omgsATescomposlinux.org> >>>> wrote: >>>> Alexandro Colorado escribió: >>>> Vamos a ver: para que no haya subjetividades, he estado leyendo las >>>> normas para crear informes: >>>> >>>>> http://qa.openoffice.org/issue_handling/basic_rules.html >>>> >>>> Como imaginaba, en ningún sitio menciona algo parecido a que quien crea >>>> un informe (issue), no tiene que proporcionar la solución. Trasladado al >>>> caso concreto que nos ocupa, creo que Marcos ha obrado correctamente y >>>> NO TIENE PORQUE PROPORCIONAR EL ARCHIVO CORREGIDO, y es tarea de la >>>> persona asignada encontrar dónde se corrige el problema. Obviamente, si >>>> >>>> >>>>> Esto no aplica en casos de traduccion donde el que reporta CONOCE el >>>>> idioma >>>>> a diferencia que el que lo toma donde no conoce el idioma y solo >>>>> conoce como >>>>> integrar el parche a la suite. > > > No estoy de acuerdo, básicamente porque no citas la fuente de esa > teoría, como te dije, por lo que no me parece objetivo. > >> Que te parece el correo del ingeniero:
> Regarding the way of reporting wrong strings, the best way is to > extract them from the sdf file and paste them twice in the comment: > once how they look now and once how they should look after the fix > (your comment from Wed Sep 26 22:11:51 +0000 2007 in issue 81978 is > exactly it). > > When there are more (let's say 20+) strings to be fixed, it makes > sense to create a small sdf file containing only these strings, fix > them directly in the file, check the file with gsicheck and attach it > to the issue. ¿Dónde dice que haya que proporcionar el archivo corregido? Para quienes no lo entiendan, dice "lo mejor es *extraer* las cadenas del sdf y *pegarlas* dos veces en el comentario: una para el aspecto actual y otra para el aspecto que deberían tener después de corregirlas". Como ya dije, si finalmente "sba" necesita algún tipo de aclaración sobre los detalles proporcionados, que lo ponga en el informe. Recalco que dice "lo mejor", no "la única forma". Que conste que coincido en que para quien va a corregirlo es "lo mejor" (= "lo más cómodo"), y así lo he venido exponiendo en todo momento. > Además, como ya > mencioné, se ha proporcionado la información detallada y necesaria para > que se pueda corregir, independientemente del detalle del fichero donde > se *cree* que puede estar el problema. No hace falta saber mucho de > idiomas para sustituir una "X" por una "Y" > >> Entonces cual es el impedimento de ponerlo? hasta ahora nadie ha puesto >> la cadena corregida. Tal vez no se ha puesto la cadena final *exacta* y *completa*, pero por favor, que levante la mano quien leyendo el texto, bien en español, bien en inglés, no comprenda el problema, así como la corrección propuesta. > así que el idioma no es > excusa. > >> Eso solo te lo puede responder Petr. o "sba" (quienquiera que sea). > Otra cosa es a quién se va a asignar finalmente el issue. Actualmente > pone "sba(sba)", que no estoy seguro de lo que significa. En teoría, > debería ser alguien con los suficientes conocimientos del idioma que se > trata como para que no haya problemas de idioma, valga la redundancia. > >> No necesariamente, ya que solo es fusionar las cadenas que tienen los >> mismos numeros identificadores. No te digo ni que sí, ni que no, pero ésa es la parte técnica que, IMHO, quien crea el informe no tiene porqué saber. > Tengo entendido que "la traducción está en manos de la comunidad", por > lo que no debe ser complicado encontrar en la comunidad con estos > requisitos (otra cosa es que se haya buscado adecuadamente, y/o otorgado > los privilegios de modificación de archivos en los repositorios). > Aparentemente, tu afirmación global es que hay un defecto de origen, es > decir, que quien se encarga de corregir los problemas sobre la > traducción al español no parece tener ni idea del idioma. ¿Hay alguna > solicitud al respecto para que esto no sea así? ¿Hay voluntarios para > esta labor? > >> No, en la historia de la comunidad no han habido tampoco tantos arreglos >> reportados. Ismael Fanlo lo hizo en el 2004 cuanod habia una colision en >> las teclas rapidas de un menu en 2.0.1 A lo mejor hay que plantearse por qué no los ha habido, pero ésa no es la cuestión, sino intentar eliminar barreras a la hora de solucionar los informes que se creen. > Pero el asunto global que me trajo a responder es el procedimiento a > seguir para crear informes. No sé si este hilo habrá arrojado luz, pero > salvo rectificación de última hora, parece haber dos opciones sobre los > datos a proporcionar, ya que en el resto de cosas parece que no hay > discordancias. Si conoces alguna fuente a la que podamos ceñirnos sin > subjetividades y que recoja todas las posibilidades que se están > debatiendo, seria genial. > >> El detalle es que la mentalidad en vez de ser receptiva fue de defensa >> lo cual ocaciono que fuera un flamewar en vez de estar abierto a las >> correciones, se dio un sentimiento de que 'no es mi problema, yo solo >> soy un usuario'. Bajo esta bandera es dificil que se haya podido avanzar >> en cualquier aspecto. El software libre se forma por usuarios que tienen >> una necesidad y buscan hasta resolverla. Los usuarios que buscan que se >> lo resuelvan son bienvenidos por contratos de soporte comercial. El software libre es colaborativo, y no cierra las puertas a nadie por su nivel técnico. Y en este caso, se desea ofrecer una mejora para todos los usuarios, no resolver un problema particular. Si el método general para corregir algo que es una mejora para toda la comunidad no es el adecuado, quisiéramos saberlo todos, pero por la documentación existente al respecto, creo que el método seguido es totalmente correcto. Si un usuario no puede crear informes sin proporcionar una solución técnica, entonces que conste en algún sitio, porque yo no he visto tal cosa como requisito. Saludos. - -- |----------------------------------------------------------------------| | http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 | | Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org | | GPG Key at http://pgp.escomposlinux.org | |----------------------------------------------------------------------| -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHEJJCQpr3kykd/aQRAhshAJ4m4ILXqHQRsJ1tSwFbRg4N1BypNQCdG6R+ QWJng/zkkwNl9gWi8nr9C0o= =h1Xo -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
