La semana pasada se anunció la disponibilidad General del SPFX en todos los tenant de Office 365. A día de hoy, ya podemos ponerlo en entornos productivos, así que vamos a aprovechar esta circunstancia para tratar de entender cómo funciona la solución del tema de Recursos que trae de serie SPFX y de esta forma, evitar errores.
Introducción
Antes de empezar a ver el funcionamiento de los recursos multidioma, vamos e explicar el funcionamiento que esperamos que tenga.
Cuando en un desarrollo ASP.NET hacemos uso de un fichero de recursos o en un desarrollo JavaScript utilizamos una librería como i18n , lo que esperamos es tener un fichero genérico con el idioma habitual de nuestra aplicación. En caso de que nuestra aplicación soporte otro idioma, agregamos otro fichero: bien resx, bien .json (con la extensión del idioma que soporta), y él mismo se encargará de traducir nuestra aplicación.
En caso de que no dispongamos del fichero de recursos de un idioma, devolverá la aplicación en el idioma definido por defecto.
Tal y como funciona SPFX, cuando creamos un proyecto (>yo @microsoft/sharepoint) en el WebPart disponemos de un fichero de «recursos» por defecto. Está ubicado en la carpeta «src->webparts->resource->loc». Dentro de esta carpeta hay dos ficheros:
- mystrings.d.ts: donde estarán almacenados el nombre para acceder a los recursos
- en-us.js: donde está la traducción de los recursos indicados en el fichero anterior.
Para poder utilizar los recursos dentro de nuestro código, bastará con importar la clase mystring de la siguiente forma:
import * as strings from 'resourceStrings';
Para utilizarlo, dispondremos de Intelisense, en el cual tendremos todos los recursos disponibles.
Vamos a ver un ejemplo básico. En el load de la clase de WebPart, añadimos en el html que nos muestre el contenido de uno de estos elementos del fichero de recursos, de manera que el resultado sea:
public render(): void {
this.domElement.innerHTML = strings.BasicGroupName + `
<div class="${styles.helloWorld}">
<div class="${styles.container}">
<div class="ms-Grid-row ms-bgColor-themeDark ms-fontColor-white ${styles.row}">
<div class="ms-Grid-col ms-u-lg10 ms-u-xl8 ms-u-xlPush2 ms-u-lgPush1">
<span class="ms-font-xl ms-fontColor-white">Welcome to SharePoint!</span>
Customize SharePoint experiences using Web Parts.
${escape(this.properties.description)}
<a href="https://aka.ms/spfx" class="${styles.button}">
<span class="${styles.label}">Learn more</span>
</a>
</div>
</div>
</div>
</div>
`;
}
Si arrancamos nuestra solución dentro del Workbench local funcionará correctamente:
A continuación, esta misma solución la desplegamos en un Tenant de Office 365 y ¿cuál es el resultado? Por lo que podéis deducir, esta claro que va a fallar…
¿Por qué falla?
Analicemos como funciona SPFX.
Si vamos al fichero de configuración de la solución ubicado dentro de la carpeta Config-> Config.json, vemos que ese documento tiene un nodo, que es «localizedResources». En este nodo está la ubicación de los ficheros de recursos de cada WebPart, en los cuales el parámetro es el idioma en el que se ejecuta.
{
"localizedResources": {
"resourceStrings": "webparts/resource/loc/{locale}.js"
}
}
En base a este funcionamiento, si utilizamos el sistema de recursos por defecto que trae SPFX, en caso de que despleguemos un WebPart y el cliente lo visualice en un idioma que no tengamos creado, en ese fichero se producirá un error.
¿Por qué no falla en el Workbench?
El motivo por el cual no falla en el Workbench, es porque se está cargando la página como si se estuviera cargando en idioma americano. ¿Cómo lo sabemos? Nos vamos a la carpeta /temp/, abrimos el fichero workbench.html y observamos que se carga como si estuviéramos en un navegador americano.
<!doctype html>
<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>SharePoint Web Part Workbench</title>
<link rel="shortcut icon" href="https://localhost:4321/node_modules/@microsoft/sp-webpart-workbench/dist/assets/server-icon.png" />
<script type="text/javascript" src="https://localhost:4321/temp/manifests.js"></script>
<script type="text/javascript" src="https://localhost:4321/node_modules/@microsoft/sp-loader/dist/sp-loader_en-us.js"></script>
<script type="text/javascript" src="https://localhost:4321/node_modules/@microsoft/sp-webpart-workbench/lib/api/workbenchInit.js"></script>
</head>
<body>
<script type="text/javascript">
window.spModuleLoader.start(window.preloadedData);
</script>
</body>
</html>
Conclusión
Aunque en un principio, la solución que se ha propuesto para solucionar el tema del multi idioma dentro de un WebPart parece una solución pensada y meditada, mi opinión es que tiene que mejorar y abordar el supuesto de que haya un idioma por defecto.
Office 365 da soporte a todos los lenguajes disponibles, y en el SPFX creo que se debería haber optado por una solución como la de las Add-In. En los Add-In indicábamos los idiomas que soportaba y cuál era el idioma por defecto.
Otra alternativa sería que funcione como hace i18n, es decir, tener un idioma por defecto, para que en el caso de que no haya traducción para ese idioma, devuelva un idioma y no un error.
¡Suscríbete a nuestras RRSS!
