Oscar Manuel Gómez Senovilla escribió:
-----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]
Estimado Oscar,
Coincido con tu opinióm, y además repito:
* se debe distinguir entre reportar un issue de traducción, y
proponerse como voluntario para traducirlo: si el usuario, como sabe
castellano, se da cuenta de que hay incongruencias, o algo no está
traducido, PERO no sabe inglés, y por ende no sabrá traducir, ¿le
decimos que NO tiene ningún derecho a reportar un issue de traducción?
¿le decimos que vaya a estudiar ingles y se ponga a traducirlo?
* quien reporta un issue sólo es el disparador de todo un proceso;
cualquiera puede loggerarse en OOo y agregar algún comentario a su
issue. En nuestro caso, cualquiera que disponga de los conocimientos
para proporcionar las cadenas exactas y/o su traducción puede hacerlo.
* a partir de esto, concluyo que lo dicho por el ingeniero de Sun NO es
una indicación de CÓMO deben los USUARIOS reportar los issues de
traducción, SINO de lo que se DEBE hacer una vez reportados: el que
sepa, que agregue su comentario al issue proporcionando, ya sea las
cadenas o un archivo.
Las instrucciones son claras en
http://wiki.services.openoffice.org/wiki/Handling_Translation_Issues
"A correctly submitted translation issue should:
* have Component set to l10n
* be assigned directly to the person responsible for fixing
translation issues for the languages listed above - currently petr_dudacek
* have the language code specified in square brackets in the
beginning of the Summary field, for example: [IT] missing translations
in File -> Open dialog
Additional information that is useful for locating the strings that need
to be fixed: [...]"
Ahí se dice claramente que todo lo que se está exigiendo actualmente en
esta discusión, es "Additional information": el USUARIO sólo debe
cumplir con los puntos de arriba.
Los cuáles, por otra parte, ¿cómo los sabrá si no están en castellano?
Me atajo: TODOS los issues que he reportado de traducción ESTÁN MAL
REPORTADOS, no cumplen con los requisitos para "A correctly submitted
translation issue". Esta página la he encontrado recién hoy, así que
deberé corregirlos!
Concluyo: Si esto fuera un proyecto serio, habría responsables de la
comunidad en castellano subscritos a [EMAIL PROTECTED], y cada vez que ven que
hay uno reportado para el idioma español, deberían revisarlo. El usuario
hispanohablante NO estaría siquiera obligado a saber esto, no estaría
obligado a enviarles un CC del issue a ellos.
Atte.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.arielconstenlahaile.com.ar/ooo/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
