On Fri, 12 Oct 2007 14:28:26 -0500, Oscar Manuel Gómez Senovilla
<[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
"On Mon, 08 Oct 2007 03:14:07 -0500, Petr Dudacek <[EMAIL PROTECTED]>
wrote:
Hi Alexandro,
yes, I'm aware of the issues, I only was quite busy in the past few
weeks, so I didn't start to fix them yet.
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.
Just let me know in case of questions or comments...
Thanks,
Petr"
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.
así que el idioma no es
excusa.
Eso solo te lo puede responder Petr.
Cualquiera con un mínimo conocimiento de inglés y/o español (el
conocimiento técnico de la ubicación de los archivos fuente de la
aplicación se le presupone) debe comprender el problema perfectamente
(como detalle extra, el informe está en inglés y en español). A pesar de
todo esto, si la persona asignada tiene algún problema, dejemos que sea
ella misma quien lo exprese. No siempre es posible predecir cualquier
problema que pueda surgir en el transcurso de la resolución de un
informe.
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.
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
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.
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
iD8DBQFHD8raQpr3kykd/aQRAt0xAJ9DlCNVhfH0lItIpYdZQgoIAGcNYACeJQ0I
l3TbfobCBc2AsvGC718Erys=
=RUCH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexandro Colorado
CoLeader of OpenOffice.org ES
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
