Memoria de traducción / búsqueda de duplicados, etc. etc.

Lugar donde se intentarán resolver problemas específicos
Responder
Avatar de Usuario
Leeg
Mensajes: 384
Registrado: 20 Mar 2014, 00:25

Memoria de traducción / búsqueda de duplicados, etc. etc.

Mensaje por Leeg » 14 Jul 2016, 22:43

¡Hola!

Sigo con Devil Survivor traduciendo con la herramienta que programé pero me estoy encontrando con un problemilla. Estoy utilizando un script de Levenshtein distance para ver si hay segmentos duplicados o con un 70% de similitud al que se está traduciendo. Al principio la cosa iba bien, pero en cuanto la memoria de traducción (un XML) se ha ido haciendo más y más grande (865 kbps actualmente, unas 37.000 líneas de texto) el rendimiento ha caído en picado y ahora tarda bastante en mostrar resultados (se congela uno o dos segundos el programa al cambiar de segmento mientras está buscando similitudes con el script de Levenshtein distance). Lo cierto es que es poco tiempo pero hace que el cambio entre segmentos ya no sea inmediato y a la larga me hace perder mucho tiempo.

Entonces mi pregunta es... ¿alguno conoce alguna manera de implementar algo parecido pero que funcione correctamente? ¿Los programas comerciales tipo SDL Trados o memoQ que hacen uso de memorias de traducción cómo funcionan en este sentido?

(También puede ser que el script esté bien pero que mi implementación sea mala...)
https://github.com/Artuvazro/DSSE/blob/ ... ml.cs#L450

Gracias :)

Avatar de Usuario
mz
Mensajes: 58
Registrado: 22 Sep 2011, 06:15
Ubicación: Argentina

Mensaje por mz » 15 Jul 2016, 02:39

No tengo nada de experiencia con esto, pero ¿no podrías simplemente calcular la Levenshtein distance entre todos los bloques de texto originales y guardar los resultados en una base de datos o algo así?

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5597
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 15 Jul 2016, 11:46

Yo me lo planteo de otra forma: ¿merece la pena complicarse?

Mira la memoria que vas consumiendo al hacer las comparaciones, a ver cuánta te va dejando en cada paso.

Avatar de Usuario
Leeg
Mensajes: 384
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 15 Jul 2016, 13:07

mz escribió:No tengo nada de experiencia con esto, pero ¿no podrías simplemente calcular la Levenshtein distance entre todos los bloques de texto originales y guardar los resultados en una base de datos o algo así?
¿Quieres decir calcularla de golpe al principio para todos los segmentos? Mmm... Pues no es mala idea, no. No se me ocurre ahora mismo como implementarlo pero no es mala idea, creo. Habría que guardar la relación entre segmentos en una base de datos sí, pero no sé si se me complicará mucho la cosa, voy a pensarlo ;)
CUE escribió:Yo me lo planteo de otra forma: ¿merece la pena complicarse?
Sí, me ahorra mucho tiempo XD
CUE escribió:Mira la memoria que vas consumiendo al hacer las comparaciones, a ver cuánta te va dejando en cada paso.
Memoria no tengo ni idea porque no lo he mirado con visual studio, pero la CPU se pone a tope cada vez que se pone a calcular la distancia. Yo creo que el problema es que lo tengo implementado en un while y se va quedando todo en memoria y no se limpia en cada iteración o algo. Lo miraré más a fondo poniendo breakpoints por ahí para ver exactamente qué paso hace que se congele el programa.

Gracias por las respuestas.

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5597
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 15 Jul 2016, 13:36

Por eso te lo comento. Esas pausas suelen ser cosa de falta de memoria, y como usáis lenguajes que la gestionan sin que el usuario tome parte, más de una vez pasa algo similar.

Avatar de Usuario
gadesx
Administrador
Administrador
Mensajes: 2003
Registrado: 24 Ene 2011, 16:43
Ubicación: El puche
Contactar:

Mensaje por gadesx » 15 Jul 2016, 16:18

un poco offtopic:
El script del baten kaitos origins en xml, casi 4MB
En el famoso notepad++ petaba cuando le daba la gana solo con abrirlo y guardar,
tuve que cambiar el textpad y sin problemas.

Avatar de Usuario
KeKo
Mensajes: 28
Registrado: 20 Feb 2015, 17:19

Mensaje por KeKo » 19 Jul 2016, 20:14

Hasta el momento yo solo he utilizado las memorias del SDL Trados Studio (compañía para la que empiezo a trabajar el mes que viene :oops:) y las de OmegaT. La ventaja de OmegaT es que es una herramienta gratuita al contrario que Trados.

Si tu tienes una memoria en un formato que sea compatible con alguna de esas 2 herramientas, cuando abras el texto que vas a traducir todos los resultados que sean concordancias totales, es decir que el fragmento a traducir sea igual que el de tu memoria, este se rellanará solo automáticamente todas las veces que salga en el texto y solo tendrás que darle a la opción de confirmar fragmento.

Sin duda Trados tiene más capacidad para soportar memorias de traducción grandes, por lo que no debería no se te debería congelar el ordenador a la hora de que el programa busque concordancias, pero puedes probar también con OmegaT a ver si te sirve alguno de los dos.

Avatar de Usuario
Leeg
Mensajes: 384
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 20 Jul 2016, 10:20

Keko:

Conozco ambos programas y sé utilizarlos XD. Lo que yo quería saber cuando preguntaba "cómo funcionan" era la mecánica que seguían a la hora de gestionar sus memorias de traducción. Lo único que conozco es la estructura del formato .tmx y porque es libre, pero eso ya lo estoy usando en mi programa. Lo que desconozco es si usan algo tipo Levenshtein distance o parecido para obtener las concordancias... Eso es lo que estoy usando yo de momento pero el rendimiento es muy malo :(

Por cierto, suerte con el curro en SDL :)


Y ya sé lo que falla en mi script, es el while. La implementación no es la adecuada pero no sé de momento cómo arreglarlo. Cuando el segmento concordante es exactamente igual al que se está traduciendo, el resultado es inmediato porque lo hago con una query de LinQ. El problema es cuando no encuentra nada exactamente igual y entonces salta a mi script de fuzzy match donde tengo Levenshten distance en un while que recorre todos los segmentos, ahí es donde se cuelga hasta que recorre todo. Supongo que tendré que buscar una forma de hacer que funcione con LinQ.

Avatar de Usuario
KeKo
Mensajes: 28
Registrado: 20 Feb 2015, 17:19

Mensaje por KeKo » 20 Jul 2016, 20:48

Leeg escribió:Keko:

Conozco ambos programas y sé utilizarlos XD. Lo que yo quería saber cuando preguntaba "cómo funcionan" era la mecánica que seguían a la hora de gestionar sus memorias de traducción. Lo único que conozco es la estructura del formato .tmx y porque es libre, pero eso ya lo estoy usando en mi programa. Lo que desconozco es si usan algo tipo Levenshtein distance o parecido para obtener las concordancias... Eso es lo que estoy usando yo de momento pero el rendimiento es muy malo :(
My bad entonces, pensaba que buscabas un programa y no el script en sí jajaja. En eso no puedo ayudar, mis conocimientos informáticos son muy limitados :(

Avatar de Usuario
Leeg
Mensajes: 384
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 23 Ago 2016, 15:19

Publico aquí para avisar de que estos días he estado mirando este asuntillo y he logrado reducir considerablemente el cuelgue que se producía al pasar de un segmento a otro cuando buscaba fuzzy matches en la memoria de traducción. Ahora es mucho más tolerable, a penas unos milisegundos, lo que no sé es si aguantará así conforme vaya pesando más la memoria, el tiempo dirá. Al final lo arreglé quitando salvajadas del loop ese donde se incluye el cálculo de la Levensthein distance, como por ejemplo eliminando declaraciones de variables dentro del loop, cosa que volvía loco al Garbage Collector (definir cosas dentro de un loop es mal). Y también lo he optimizado un poquillo a base de quitar cosas innecesarias, como que se copien los segmentos que van saliendo como fuzzy matches consecutivamente y se vayan sustituyendo hasta dar con el más alto cuando acaba el loop, ahora solo se copia el más alto. Tengo que mirar si lo puedo optimizar más pero de momento ya me doy con un canto en los dientes. ;D

Responder