DotNetNuke 5.5 a introduit une nouvelle donnée dans l'univers des compétences DotNetNuke : la "localisation" de contenu. Ce faux-ami hérité de l'Anglais "Localization", a trait à la traduction du contenu et l'adaptation de l'interface à la culture locale. DotNetNuke avait déjà fait un pas en ce sens dès la version 3.x, en introduisant le système de stockage des libellés multi-lingue (resx). Aujourd'hui, DotNetNuke (et son architecte des données, Shaun Walker), ont fait un grand pas dans la direction d'une vraie "localisation". Nous verrons dans cet article comment procéder au déploiement des fonctions, qui restent inactives par défaut, et nous pourrons constater que le système livré dans la version 5.5.x n'est pas encore vraiment mature ; mais rassurez vous, la Core Team travaille à améliorer le système et le rendre plus fiable.

Activer la localisation du contenu sur l'hôte

La localisation du contenu s’active pour l’instance et permet de faire bénéficier de ses fonctions l'ensemble de ses portails. Pour l'activer, naviguez sur le menu Hôte > Paramètres de l’hôte, puis dans la section « Paramètres avancées » et « Autres paramètres ». Cochez l'option « Activer la localisation de contenu ».


Dès lors, la localisation de contenu est disponible sur les portails, permettant la réalisation d'une version traduite des contenus des modules, des pages, et paramètres. Cela permet d'offrir un contenu entièrement traduit et adapté à la culture du visiteur tout en conservant une liaison latente entre les différentes traductions des pages et modules du site.

Activer la localisation sur un portail

Il s’agit maintenant d’activer la localisation au niveau du portail afin de bénéficier des fonctions avancées. Rendez-vous donc sur le menu Sites > Langues, puis cliquez sur « Activer la localisation de contenu » qui apparaît en haut à droit de la grille dressant la liste des langues installées sur votre instance.


Lorsque vous cliquez sur ce bouton, un message de confirmation vous informe du caractère irréversible de l’action.  En effet, une fois la localisation de contenu activée, il n’est plus possible de revenir en arrière sans passer par une restauration de la base de données. De ce fait, il est conseillé de faire un backup de la base de données au préalable.  Dans le même ordre d'idées, la culture actuelle du site (Cf. : la "langue" par défaut) ne pourra plus être changée par la suite, car le site adopte le postulat que les traductions ne se font que d'un sens, de la langue originelle vers ses déclinaisons traduites. Dans le reste de ce document, nous nommerons les éléments rattachés à la langue par défaut comme "la version maître" (Cf. "du module" ou "de la page" ou "des paramètres").

Commencer la traduction

A cet instant, nous vous recommandons d'avoir installé au moins un autre pack de langue pour DotNetNuke, par exemple, le pack de langue fr-FR disponible sur Dotnetnuke France.

Une fois la localisation de contenu activée sur votre site, vous pouvez commencer à créer les versions traduisibles des pages de votre site : le processus de traduction commence toujours par la création d'une "copie" de la page à traduire vers la langue de traduction. Cette étape peut avoir été faite automatiquement si vous avez spécifié l'option lors de la création. Elle peut également être faite page par page.
Pour cela, rendez-vous sur la page maître, et cliquez sur "Créez la version localisée". A la création, la page maître et les modules qu'elle contient sont copiées vers la page traduisible et le contenu des modules est affiché dans la langue par défaut.

Une fois la version locale de la page maître créée, vous pouvez éditer le contenu de ses modules. 

Par défaut, le nom des pages localisées est modifié, le code de la culture est suffixé au nom de la page maître.

Par exemple,  une page nommée "Config" dans la langue d'origine sera nommée "Config fr-FR" dans sa version Française.




Le paramétrage des pages reste quant à lui totalement indépendant des liaisons parent/enfant. Ainsi, une gestion fine des rôles en fonction de chacune des traductions, un affichage spécial du Skin, un titre de page différent, des mots-clefs adaptés, restent autant de paramètres locaux dont la personnalisation reste possible. Et comme vous vous en doutez, il en va de même pour les modules.

Lors de l’édition d’un contenu, par exemple avec le module HTML, un rappel du contenu du module maître est affiché au dessus de la zone d’édition.




Parfois les cultures partagent des éléments communs, d'autre fois, même les caractères d'imprimerie sont différents ... Vous pouvez donc choisir de ne pas traduire un module, laissant son contenu apparaître dans la langue initiale, choisir que les modifications faites sur l’un soient reportées sur l’autre de manière transparente, ou au contraire de spécifier son détachement du module originel afin de présenter un contenu différent. Ces options sont accessibles depuis la section « Localisation » des paramètres de la page.



Cette interface permet aussi le suivi du travail de traduction. Nous aurions aimé avoir tout cela disponible dans la barre des tâches vue par l'éditeur de page et les éditeurs de module. L'expérience montre que les tâches répétitives doivent être accessibles rapidement sinon les traducteurs risquent de passer un checkpoint sans même le vouloir. Espérons que l'interface évoluera dans ce sens par la suite.

Cela implique donc que le traducteur joue le jeu, et accepte de se rendre systématiquement dans les paramètres de la page afin de signaler les contenus dont la traduction est achevée. Cette synthèse est visible sur les paramètres de la page originelle (Aka. : la page Maître), où effectivement vous pouvez retrouver une vision globale du travail de traduction, module par module et langue par langue. 



Finalement, si l'ensemble des modules d'une page maître sont traduits dans toutes une culture donnée, la page obtient le statut "Traduit" pour cette culture et peut être rendue publique.
Dans le même ordre d'idées, nous nous attendions à ce que, lorsqu'un module est ajouté sur la page maître et n'est pas traduit, elle perde ce statut pour obtenir le statut "Non traduit" jusqu'à action des traducteurs, entrant de nouveau dans la boucle du "Reste à faire" de l'équipe... nous nous attendions également à ce que ce module soit automatiquement ajouté sur les pages enfant et signalés "Non traduit". or, ce n'est pas ce qui se produit.

Un module ajouté sur la page maitre n'est pas automatiquement copié sur les pages localisées, il faut cliquer dans l'interface de localisation afin de le déployer sur les pages traduites.


D'autre part, un module ajouté directement sur la page localisée possède la culture maitre au lieu de la culture de la page sur laquelle on l'a inséré... On ne peut visiblement pas le traduire... bizarre, donc. Si l'on veut traduire un module, il faut travailler sur la page maître. Tout module ajouté sur une page localisée sera propre à la page localisée, bien que sa culture soit erronée.

A ce stade, même le module non traduit est visible pour le public, la page conservant son statut initial "Traduit".