Sufijos TL y VL

EBS tiene la capacidad de ser multilenguaje, esto permite que las pantallas o fronted tengan esta característica de traducción; por defecto y estándar el idioma es inglés. (algunos valores a nivel de backend permanecen en idioma estándar)

Los sufijos significan:

TL: Tabla de lenguaje
VL: Vista de lenguaje

¿Cómo EBS logra la traducción de un valor en varios idiomas?

Se almacena la información en una tabla independiente por cada entidad o concepto; veamos un ejemplo con un modelo:

Podemos observar que la "tabla base" tiene una relación de "uno a muchos" con la "tabla traductora". El diagrama anterior es tomado de un ejemplo real del ERP; podríamos concluir de el:

"La tabla que representa los programas concurrentes "fnd_concurrent_programs" (tabla base) tiene la capacidad de almacenar sus datos en varios lenguajes, pues contiene su propia tabla traductora fnd_concurrent_programs_tl"

Con el diagrama anterior de la tabla base y de lenguaje podríamos realizar un JOIN/UNION, dando como resultado todas las traducciones que tiene la tabla base, miremos un ejemplo:

Se puede observar en la consulta anterior, que se está realizando el JOIN/UNION por la columna concurrent_program_id y application_id, también de programas que contengan como nombre corto "GL" y se ordenó por esta columna y la de lenguaje.

Puede suceder que un programa no este traducido en algún idioma o se hubiera almacenado con la misma traducción para varios idiomas, tal caso debería corregirse.

Ya se resolvió el TL, ¿Ahora, cómo es la vista de lenguaje VL?

Primero que nada, debes entender que es una vista, de lo contrario podrías confundirte, por tanto:

Si NO sabes que es una vista, primero aclara este concepto tanto de forma teórica como práctica
Si sabes, continúa leyendo

Hasta el momento este JOIN nos traería todos los lenguajes disponibles, ¿pero cómo EBS realiza el filtro para un solo lenguaje dependiendo de la sesión del usuario?, ¿Cómo se podría añadir este filtro en la clausura WHERE, la respuesta se encuentra en dos puntos:

En ORACLE existe una función llamada USERENV, esta función tiene la finalidad de tomar información de la sesión que se conecta, de esta manera extraen de aquella función el lenguaje. Para familiarizarnos ejecutemos la siguiente sentencia en una conexión de BD:

SELECT USERENV('LANG') FROM dual;

Veremos que retorna el código corto del lenguaje, dependiendo del idioma de nuestra sesión, por ejemplo:

Sesión con idioma Portugués

Sesión con Idoma American

2. Las tablas de lenguaje tiene una columna "LANGUAGE", esta almacena el código corto del lenguaje. Entonces, aquí está la clave en la cláusula WHERE, se filtra la columna "LANGUAGE" de la tabla traductora "TL" igualando con esta función que hemos visto en el punto uno (USERENV).

Modificando la sentencia de JOIN/UNION y agregando esta funcionalidad tendríamos algo similar a esto:

Podemos determinar varias cosas de la consulta:

La última condición, tiene integrada la funcionalidad de USERENV
El ordenamiento por lenguaje no está, debido a que el LANGUAGE es filtrado con la función USERNV y siempre retornara US, por tanto no es necesario el ordenamiento por tal columna
La columna LANGUAGE tiene el valor de US, esto significa que el idioma de la sesión actual es AMERICAN

De esta manera dependiendo el idioma de la sesión actual, nos retornaría el valor correspondiente de idioma.

Conclusión: Una Vista de lenguaje (VL) su núcleo o fundamento sería el JOIN de la "tabla base" unida con su "tabla traductora", añadiendo a este JOIN, la condición o filtro del leguaje de la sesión por medio de la función USERNV, de esta manera, la vista retorna solo un valor según el idioma de la sesión en que se conecta el usuario a la base de datos.

Práctica:

Te invito a ver la siguiente vista: "fnd_concurrent_programs_vl" y explora que pasa si ejecutas una consulta cambiando el idioma de la sesión.

Algunas dudas, para aclarar:

¿Si al ejecutar una vista de lenguaje no retorna datos, que puede ser? Con los conceptos aprendidos anteriormente, podremos apuntar a tres afirmaciones muy posibles de esta novedad:
1. Que la tabla de traducciones no tenga ningún valor
2. Que la sesión del usuario su idioma no se encuentre registrado en la "tabla traductora" dándonos como resultado cero filas para la consulta
3. Que la vista se encuentre mal construida
¿El código del lenguaje puede ser personalizado?, NO y no tendría sentido hacerlo de tal modo, carecería de diseño. El código corto se basa en el estándar mundial ISO, así como hoy en día reconocemos el código corto de moneda "USD" como dólar y no "USD2, DOLAR, DOLARES, MONEDAESTADOSUNIDOS"
Siempre se nombró sesión de Base de datos, ¿el usuario puede seleccionar su idioma?, si puede elegirlo desde la aplicación y puede realizar hasta modificaciones desde la configuración de su perfil, en caso de querer ver más traducciones aparte de su propia sesión, algunas pantallas/fronted ofrecen el icono del planeta en el que podrá visualizar las diferentes traducciones en caso de existir
¿Un sufijo VL solo puede tener la unión de dos tablas?, NO, puede añadirse cuanta información se requiera, el VL solo informa que su origen o finalidad es brindar una traducción posible para alguno de los campos del concepto principal
¿La función USERENV solo retorna el código corto del lenguaje?, NO, esta función logra retornar otros valores, te aconsejo ir a la documentación publica oficial de ORACLE que te detallara aún más

Page updated

Google Sites

Report abuse