Re: [GNU-traductores] Fwd: Re: Glosarium.py

[Oscar Campos]

Respondiendo en quote al correo se Sergi...

>
> Hola,
>
> Lo primero, muchas gracias a Óscar por su versión del buscador, me
> está permitiendo aprender un montón sobre Python. De hecho, comparadas,
> la suya es un Mercedes Benz, ¡y la mía es una carreta! ;)

Yo tampoco nací sabiendo de hecho, aún aprendo algo nuevo cada día (o
cada pocos días)

>
> Yo sólo soy un  principiante y esto es un excelente ejercicio para mí,
> muy interesante, de verdad.
>
> Al principio tenía el mismo problema que Dora para ejectuarlo. Lo metí
> en $PATH y se resolvió. Lo he estado probando con varios textos de los
> que solemos usar y os comento mi impresión:
>
> Que extraiga directamente el glosario de la web es estupendo para que
> se "actualice" sólo, pero encuentro la siguiente dificultad: al usar el
> glosario directamente de la web, busca los términos exactamente como
> están escritos en ese glosario. Entonces, por ejemplo:
>
> - "Open source" > sólo lo encuentra si en el texto aparece
> entrecomillado, como en el glosario.

Esto no es problema puesto que se pueden obviar las comillas que no se
traducen

>
> - Free Software Foundation (FSF) y otros... > sólo los detecta si
> les sigue la abreviatura entre paréntesis.
>

Una aplicación es tan inteligente como el programador que la programa,
por desgracia, yo no es que sea una lumbrera pero en este caso lo que es
necesario es una normalización del formato.

¿Van a aparecer todos los terminos abreviados entre paréntesis? En caso
afirmativo, ¿solo van a aparecer entre paréntesis abreviaturas o también
otro texto?

Hay que definir (normalizar) este formato para poder tomar una decisión
coherente en todas las coincidencias.

> - Lax, permissive license > no detectaría "lax license" ni "permissive
> license".

Leer el párrafo anterior y adaptar paréntesis por "comillas" aunque aquí
es más complejo ya que una palabra puede ser compuesta (la forma más de
una palabra) y es muy complicado saber si nos referimos a dos palabras
separadas por comas o no.

Habría que definir un formato específico para eso, tipo:
    [Lax/Permisive] license

Así sería mucho más sencillo parsear el término

>
> Otro detalle que se puede resolver es que los términos formados por
> más de una palabra, que se encuentren divididos entre dos líneas, no
> los detecta.
>

Claro, eso es un daño colateral de contar por líneas, habría que pensar
y definir como solucionarlo

> También tiene un pequeño problema que ya me encontré y no he podido
> resolver, y es que incluye en la búsqueda palabras derivadas, por
> ejemplo, detecta "network" cuando el término es "work" o "seems"
> cuando el término es "see", etc.
>

Eso se puede solucionar con expresiones regulares más complejas en lugar
de hacer búsquedas en bruto (if term in line)

> En resumen, creo que ambos programas son útiles, y «glosarium» más,
> pero todavía hay que pulirlos, teniendo en cuenta estos detalles para
> poderlos mejorar en el futuro. Mientras los traductores y revisores
> hagamos bien nuestro trabajo, no es problema, es una herramienta más
> que podemos usar, mientras la vamos afinando mejor.
>

Al estar glosarium colgado en github cualquiera puede hacerle un fork y
colaborar cuando quiera.

Salud.

-- 
Join the Free Software Foundation and become Free as in Freedom