LKLangDetect: herramienta de análisis de idioma de un conjunto de documentos

En gestión de proyectos hay tareas que, sobre el papel, parecen secundarias, hasta que, por ejemplo, llega el momento de cerrar el proyecto y descubres que no lo eran tanto.

Una de ellas es la documentación final. Manuales, listas, hojas de datos, presentaciones, informes, certificados, tablas, PDFs, excels, documentos de terceros… y muchas veces, además, en distintos idiomas.

Y ahí aparece un problema muy poco vistoso, pero muy real: necesitas saber rápidamente qué documentación está en el idioma correcto y cuál no. No para hacer una auditoría documental compleja. No para montar un sistema documental gigantesco. Simplemente para responder a una necesidad muy práctica de proyecto:

identificar qué documentos están en un idioma distinto al esperado y cuáles necesitan revisión, traducción o sustitución.

De esa necesidad nace LKLangDetect.

No como una idea abstracta ni como una demo tecnológica, sino como una herramienta creada desde una situación muy concreta de proyecto: una carpeta llena de documentación, formatos diferentes, idiomas mezclados y muy poca visibilidad para tomar decisiones rápidas.

LK Lang Detect

En este artículo vamos a contar precisamente eso:

• de dónde surge la necesidad,

• cómo se planteó la solución,

• cómo se construyó primero un prototipo en consola,

• y cómo esa idea terminó evolucionando hasta una versión v1.0 con interfaz gráfica, lista para ser usada por otras personas dentro de un entorno real de trabajo.

Y además,

👉 al final del artículo podrás descargar la aplicación directamente

👉 y también tendrás acceso al código fuente, para que puedas modificarla y adaptarla a tu propio proyecto

Porque la idea no es solo enseñar la herramienta, sino que puedas usarla y evolucionarla.

El origen: un problema real dentro del proyecto

En un proyecto industrial, la documentación no llega ordenada, homogénea y perfectamente preparada.

Llega como suele llegar todo en proyecto:

• de diferentes proveedores

• en distintos momentos

• en múltiples formatos

• y, muy habitualmente, en distintos idiomas

Durante la ejecución, esto no suele ser un problema crítico. Cada equipo trabaja con su documentación, se entienden los contenidos y el proyecto avanza.

Pero hay un momento en el que todo cambia:

👉 la fase de cierre y entrega final

Es ahí donde aparece la exigencia real:

• el cliente necesita la documentación en su idioma

• los documentos deben ser coherentes

• la entrega debe ser completa y consistente

Y es en ese punto donde te encuentras con la realidad:

• carpetas con cientos de archivos

• nombres poco claros

• versiones duplicadas

• documentos mezclando idiomas

• y, sobre todo, cero visibilidad rápida

⚠️ El problema no es técnico, es de gestión

El problema no es que no sepas traducir documentos. El problema es que:

no sabes cuáles necesitas traducir

dando visibilidad al estado de la documentación

🧠 El cuello de botella real

Si lo simplificas, todo se reduce a que tienes una carpeta así:

/Documentation_Final/
    /Manuals/
    /Datasheets/
    /Certificates/
    /Drawings/

Y dentro tienes documentos PDFs, Excel, Word, Presentaciones, documentos técnicos varios...

Y la única forma de saber el idioma es: 👉 abrir archivo a archivo

⛔ La solución “manual”

El proceso típico sería:

1. abrir documento

2. leer

3. identificar idioma

4. anotar

5. pasar al siguiente

Multiplica esto por 100, 200, 500 documentos. El resultado es: tiempo perdido, errores humanos, falta de trazabilidad, frustración y lo más importante "ninguna visión global del estado real de la documentación"

Aquí es donde aparece la idea que da origen a la herramienta. No necesitas un sistema complejo, no necesitas inteligencia artificial avanzada. Necesitas algo mucho más simple:

una forma automática de recorrer todos los documentos y decirte en qué idioma está cada uno

Nada más. Pero ese “nada más” cambia completamente la situación.

La idea: simplificar el problema

Llegados a este punto, el problema está claro. No es falta de documentación, no es falta de herramientas, no es falta de capacidad técnica. Es falta de visibilidad rápida.

🧠 El cambio de enfoque

En lugar de pensar en:

• traducir automáticamente

• clasificar documentos por tipología

• reorganizar toda la documentación

El enfoque fue otro: no resolver todo el problema, sino resolver el primer cuello de botella. Y ese cuello de botella era: 👉 identificar el idioma de forma masiva

⚙️ Qué debería hacer la herramienta

Una herramienta que:

1. recorra una carpeta completa

2. lea cada documento (independientemente del formato)

3. extraiga el texto

4. detecte el idioma

5. genere una lista clara con los resultados

🎯 Principios de diseño

Desde el principio se definieron una serie de reglas:

1. Simplicidad: La herramienta debe hacer una cosa… y hacerla bien.

2. Independencia del proyecto: Debe funcionar con cualquier estructura de carpetas.

3. No intrusiva: No modifica documentos. No reorganiza nada.Solo analiza.

4. Transparente: El usuario debe poder ver claramente:

• qué archivo se ha analizado

• qué resultado ha dado

• si hay dudas o errores

5. Accionable: El resultado debe servir para tomar decisiones rápidas.

Desde el punto de vista técnico, el problema también se simplifica mucho si lo miras bien:

• no necesitas leer todo el documento

• no necesitas entender el contenido

• solo necesitas suficiente texto para detectar el idioma

Esto permite hacer el proceso rápido, evitar complejidad innecesaria y soportar múltiples formatos

🧪 Primera validación mental

Antes de escribir una sola línea de código, la idea se puede validar fácilmente: Si consigo una tabla como esta:

Documento	Idioma	Confianza
manual_01.pdf	inglés	alta
lista_spare.xlsx	español	media
datasheet_A.docx	alemán	alta

👉 ya tengo el problema medio resuelto.

Primer prototipo: modo consola

Una vez definida la idea, el siguiente paso fue claro: construir algo que funcionara lo antes posible, sin interfaz, sin diseño, sin pensar en el usuario final.

Solo en validar que:

El prototipo se planteó como un script en Python con una lógica muy directa:

1. recibir una ruta de carpeta

2. recorrer todos los archivos

3. filtrar los formatos soportados

4. extraer texto de cada documento

5. detectar el idioma

6. guardar el resultado

El primer resultado no era una interfaz, era un Excel con columnas como documento, idioma, confianza en el idioma predicho, ruta, estado.

Prototipo - Versión consola

🧠 Qué se validó en esta fase

El prototipo permitió validar lo importante:

✔ es posible recorrer toda la documentación

✔ es posible detectar idioma automáticamente

✔ es posible generar una visión global

✔ el output es útil para tomar decisiones

Aquí ocurre algo muy interesante: el prototipo ya funcionaba, pero también era evidente que: no era usable para otras personas porque requería ejecutar scripts, requería entorno Python, no era visual, no era intuitivo.

Y ahí aparece el siguiente paso natural: hay que desarrollar una interfaz gráfica y buscar una manera de distribuirla.

👉 pasar de herramienta técnica a herramienta de proyecto

Evolución del motor: de script a herramienta

funcionar no es suficiente

Si la herramienta iba a usarse en un entorno real de proyecto, tenía que ser:

• más robusta

• más flexible

• más predecible

⚙️ Paso 1: ampliar formatos

En el prototipo inicial, el soporte de formatos era limitado. La herramienta tenía que adaptarse a la realidad y poder dar soporte a más formatos: PDF, DOCX, XLS, XLSX, PPTX, CSV, TXT, HTML, XML, MD y RTF, cada uno con su propio método de extracción de texto.

🧩 Paso 2: arquitectura de extractores

Cada formato tiene su propio extractor. En lugar de intentar un sistema genérico, se definió una estructura clara:

• función específica por tipo de archivo

• responsabilidad única

• comportamiento controlado

🧠 Paso 3: control del texto analizado

No todos los textos sirven igual para detectar idioma.

Problemas detectados:

• textos demasiado cortos

• contenido técnico (códigos, tablas)

• ruido en documentos

Solución:

👉 introducir parámetros configurables

Por ejemplo:

• número mínimo de caracteres

• límites de lectura por documento

• control de hojas en Excel

• control de páginas en PDF

Esto se externalizó a un archivo de configuración JSON.

⚠️ Paso 4: gestión de errores (crítico)

En un entorno real, los errores no son excepciones, son la norma.

Se diseñó el sistema para que:

• un error en un archivo no detenga el proceso

• cada fallo quede registrado

• el usuario pueda identificar qué ha pasado

Esto se refleja en los estados:

• OK

• Dudoso

• Error

• No soportado

📊 Paso 5: enriquecer la información

El output dejó de ser solo “idioma”. Se añadieron datos clave: confianza de detección, número de páginas (o equivalente), tamaño del archivo, fecha de modificación y rutas (relativa y absoluta)

👉 Esto permite un análisis mucho más útil desde PM.

🧠 Paso 6: incluir lo que no funciona

Una decisión muy importante: incluir también los archivos no soportados

En lugar de ignorarlos, se decidió: mostrarlos en resultados y marcarlos como “No soportado”

Esto aporta:

• visibilidad completa

• control real de la documentación

• cero zonas ocultas

🧭 Preparado para el siguiente salto

En este punto, el motor ya estaba listo, pero seguía habiendo una limitación clara: 👉 solo podía usarlo alguien técnico, Y eso nos lleva directamente al siguiente paso:

convertirlo en una herramienta accesible

De herramienta técnica a producto usable

Aquí aparece una decisión importante: si esto aporta valor, tiene que ser usable por cualquiera

No solo por quien lo desarrolla.

🎯 Objetivo de la interfaz

La interfaz no se planteó como algo estético. Se planteó como una capa para:

• simplificar el uso

• hacer visible el proceso

• facilitar la interpretación

• permitir la distribución

🎨 Diseño orientado a uso real

La interfaz se diseñó con criterios muy prácticos:

✔ claridad: nada de información innecesaria.

✔ feedback constante: El usuario siempre sabe:

• qué está pasando

• cuánto falta

• qué archivo se está procesando

✔ códigos visuales: Se añadieron colores por estado:

• verde → OK

• amarillo → Dudoso

• rojo → Error

• gris → No soportado

✔ acceso directo a archivos: doble clic → abre carpeta

✔ modo revisión: Se añadió botón “Expandir resultados” para centrarse solo en la tabla cuando hace falta.

✔ modo claro / oscuro: para adaptarse al entorno de trabajo y las preferencias del usuario.

LK Lang Detect - Versión con interfaz de usuario

⚙️ Tecnología elegida

Para la interfaz se utilizó CustomTkinter, porque es ligero, rápido de implementar y sin dependencias complejas.

En este punto, la herramienta deja de ser “un script útil” y pasa a ser una aplicación usable en proyecto

LKLangDetect v1.0: qué aporta realmente en un proyecto

🔍 Antes vs Después

Antes, la situación típica era:

• carpeta con cientos de documentos

• idiomas mezclados

• revisión manual

• incertidumbre

Después de usar LKLangDetect:

• lista completa de documentos

• idioma identificado

• nivel de confianza

• estado claro

• visibilidad total

⚙️ Qué incluye la versión v1.0

📂 Análisis completo de carpetas

• soporte de subcarpetas

• recorrido completo

📄 Soporte de múltiples formatos

• PDF

• Word

• Excel

• PowerPoint

• HTML, XML, MD, RTF

🌍 Detección de idioma

• idioma identificado

• código de idioma

• nivel de confianza

📊 Tabla de resultados

• información completa por documento

• ordenación por columnas

• visualización clara

🎨 Visualización por estados

• OK

• Dudoso

• Error

• No soportado

Con colores asociados para facilitar lectura rápida.

🔎 Funcionalidades de uso

• doble clic para abrir carpeta

• botón directo de acceso

• modo expandido de resultados

🌗 Interfaz adaptable

• modo claro

• modo oscuro

• modo sistema

📤 Exportación a Excel

• resultados completos

• lista preparada para trabajar

  
  

🚀 Uso real en proyecto

En la práctica, el flujo pasa a ser:

1. seleccionar carpeta

2. ejecutar análisis

3. revisar tabla

4. exportar

5. actuar

Lecciones aprendidas

Desarrollar LKLangDetect no ha sido simplemente construir una aplicación. Ha sido un ejercicio bastante claro de algo que en proyectos ocurre constantemente:

detectar un problema real, entenderlo bien y resolverlo con la mínima complejidad posible

👤 Lección: no todo necesita una gran solución: reducir el problema a su forma más simple

👤 Lección: primero validar, luego construir

El prototipo en consola fue suficiente para validar:

• que la idea funcionaba

• que el output era útil

• que el problema realmente se resolvía

Sin ese paso, es muy fácil:

• sobre-diseñar

• perder tiempo

• construir algo innecesario

👤 Lección: si solo tú puedes usarlo, no sirve

Ha de ser:

• accesible

• distribuible

• usable

🚀 Lo que viene después

A partir de aquí, el camino está claro. Se pueden añadir mejoras como:

• filtros por estado

• buscador de documentos

• exportación filtrada

• OCR para documentos escaneados

• integración con workflows

🎯 Conclusión

Muchos problemas en proyectos requieren claridad, y muchas veces, esa claridad se consigue con algo tan simple como: una herramienta bien pensada

LKLangDetect es un ejemplo claro de cómo un problema real, bien entendido, se convierte en una solución simple y con impacto directo

💬 ¿Te suena este problema en tus proyectos?

Si alguna vez te has encontrado:

• revisando carpetas interminables de documentación

• abriendo archivos uno a uno para ver en qué idioma están

• intentando hacer una lista manual sin perderte

• o simplemente sin tener claro qué documentación está lista y cuál no

👉 entonces este problema no es teórico. Es real.

📥 Pruébalo en tu propio proyecto

Puedes descargar la herramienta directamente y probarla con tu propia documentación:

👉 Descarga de la aplicación (v1.0)

LKLangDetect_v01.00.zip

Descargar ZIP • 48.12MB

👉 Acceso al código fuente

LKLangDetect_v01.00_SourceCode.zip

Descargar ZIP • 439KB

Úsala, modifícala, adáptala.

La idea no es solo enseñarla. Es que te sirva.