Introducción
Bien, como mencioné en Parte 1, un usuario de mi grupo de usuarios me preguntó recientemente sobre la localización de un modelo de datos de Power BI, incluidos nombres de tablas, nombres de columnas, nombres de medidas, así como títulos para visualización, etc. serán al menos dos partes de este artículo de blog, tal vez tres o más. En En la parte 1, localizamos los nombres de tablas, columnas y medidas en nuestro modelo de datos. En la Parte 2, logramos que las pruebas funcionaran con Power BI Premium y usamos una tabla de localización y medidas para resolver los títulos localizados. Sin embargo, debido a que los títulos y las leyendas de los ejes no tienen la magia fx , no pudimos localizar esas cosas e identificamos un problema con la traducción real de cosas como los nombres de los meses que estaban en los datos mismos. Continuemos donde lo dejamos.
La manera fácil
Traducción del navegador. Verá, todos los navegadores modernos tienen la capacidad de traducir una página a un idioma extranjero. Entonces, para probar esto, creé una copia completamente no localizada de mi informe, que se ve así en inglés:
Así que creé títulos de eje personalizados, leyenda, título visual, etc. Ahora simplemente le pedí a Edge que tradujera la página al alemán y aquí está el resultado:
No sé mucho, si es que algo de alemán, pero esto me parece razonable. Y bueno, incluso tradujo los nombres de mis meses al alemán. ¡Esto significa que los datos dentro de mi modelo se pueden traducir a otros idiomas automáticamente! ¡Eso es muy elegante! Mejor aún, cuando edito mi informe, incluso mis paneles Visualizaciones y Campos se traducen al alemán:
Y tenga en cuenta que esto funciona en Pro o Premium, por lo que no necesita Premium si usa la función de traducción del navegador.
Entonces, ¿hemos terminado? Voy a decir «sí» para todos los propósitos prácticos porque si no usas esta técnica, las cosas comienzan a volverse infinitamente más difíciles. Además, esta solución es «elegante». ¿Por qué reinventar la rueda cuando la gente ya ha dedicado tanto tiempo y esfuerzo a la tecnología de traducción que simplemente requiere un poco de educación del usuario para aprender a usarla? ¡No es necesario traducir nada ni Premium!
El camino difícil
Bien, para demostrar lo difícil que se vuelve esto si no usamos la traducción del navegador, primero abordemos qué opciones tenemos para aquellos elementos de texto que no incluyen el fx botón. Bueno, teóricamente podríamos usar nuestra tabla de localización y medidas para crear elementos visuales de Card que mostraran el texto localizado correcto y superpusieran los elementos visuales apropiados. Pero esa no es exactamente una solución elegante. Y, dado que no puede rotar las imágenes de la tarjeta, realmente no tiene ninguna opción para el título del eje y. ¿Y cómo explica exactamente cosas como el texto de la leyenda que es significativamente más corto o más largo en un idioma en comparación con otro?
¿Y qué hay de traducir los datos reales como los nombres de los días de la semana y los meses? Eso es aún más doloroso. Lo primero que pensé fue qué pasaría si construyera una tabla simple de solo los nombres de los meses con columnas adicionales para cada localización. Podría relacionar esto con mi tabla de fechas y luego construir una jerarquía para el eje x de cada una de las columnas de nombre del mes y luego usar seguridad a nivel de objeto (OLS) para que solo se pueda leer una de las columnas … Déjame ser claro, esto no funciona en lo más mínimo. Oh OLS, eres inútil, inútil, basura. OLS, me has fallado por última vez !! Verá, en el momento en que Power BI intenta mostrar un objeto visual para el que una columna «no existe», no maneja el problema correctamente, solo obtiene un objeto visual roto. Y así, por qué OLS es esencialmente una «característica» inútil.
Bueno, intentemos algo más y para que esto sea un poco más realista, creemos una tabla de hechos rápida y establezcamos la columna Valor en Moneda (Moneda general):
Facts =
VAR __Table = ADDCOLUMNS('Dates',"Value",YEAR([Date])+MONTH([Date])+DAY([Date]))
RETURN
UNION(__Table, __Table, __Table)Ahora creamos una tabla «Dates2» como esta:
Dates2 =
UNION(
ADDCOLUMNS(
'Dates',
"Language","en-US"
),
SELECTCOLUMNS(
ADDCOLUMNS(
'Dates',
"Language","de-DE",
"German Month",
SWITCH([Month],
"January","Januar",
"February","Februar",
"March","Marz",
"April","April",
"May","Mai",
"June","Juni",
"July","Juli",
"August","August",
"September","September",
"October","Oktober",
"November","November",
"December","December"
)
),
"Date",[Date],
"Month",[German Month],
"Weekday",[Weekday],
"Year",[Year],
"Language",[Language]
)
)Entonces, nuestra tabla Dates2 tiene 2 filas para cada fecha que tiene un nombre de mes en inglés o un nombre de mes en alemán, así como una columna de idioma que especifica qué idioma se usa en la fila. Creamos la relación entre las dos tablas y es Many-to-Many. Ok, Many-to-Many no es el fin del mundo, configuramos dos roles de RLS, inglés y alemán, que esencialmente tienen reglas de RLS como:
[Language] = "de-DE"Y lo probamos y funciona. Claro, parece un poco extraño si no usa una regla de RLS con los nombres de los meses en inglés y alemán en el eje, pero podríamos simplemente hacer cumplir la regla de que todos deben ser miembros de un rol de RLS. Pero, funciona para un extremadamente modelo de datos simple. No puedo imaginarme tratando de hacer esta técnica para ningún tipo de modelo de datos complejo.
Conclusión
La traducción del navegador es tu amiga.
