Navigation multilingue

Bonjour

Je souhaiterai savoir s’il existe un moyen de faire une page principale sur laquelle l’utilisateur pourrait choisir la langue de visualisation du support lors de sa génération au format Web. En effet, actuellement je crée un répertoire par langue et un module de publication. Ce qui fait en fait au final x module par langue, mais j’aurai aimé avoir la possibilité de ne publier qu’un seul module qui via la page d’accueil (par exemple une image drapeau) reverrait vers le module complet de la langue. Il semble qu’on ne puisse pas utiliser les modules comme liens vers un objet…

J’utilise Opale 3.7.

Un grand merci pour vos idées ou vos pistes
Excellente journée

Bonjour, et bienvenu !

J’ai pas bien compris l’histoire des x modules par langue.

1 « J'aime »

Vous gérez combien de langues ? et combien de modules Opale ?

Bonjour Sam et merci pour la réponse

Je gère souvent 3 langues différentes, comme présenté sur la photo. Et pour chaque langue j’organise mon contenu par répertoire :slight_smile:

Un grand merci
Excellente journée

Re bonjour

Mais du coup je me demande si la solution ne serait pas plus simple de la faire avec la génération via un module Emeraude :

et reprendre par section ce que j’ai à la place des modules par langue dans le rep 99. delivery…

Une idée comme çà…

Le seule problème de cette « Solution » c’est qu’au niveau de la génération Web, on ne peut que lier des modules… et que le module Emeraude n’entre pas à priori comme objet accepté…

Excellente journée

Bonjour,

Nous proposons Opale en Français, Anglais et Espagnol. Pour que vos publications soit entièrement traduits il serait bon de séparer les trois langue en trois ateliers SCENARI différents chacun utilisant la bonne version traduit d’Opale.
En effet la publication web d’Opale contient bon nombre de chaînes de caractères « en dur » qui seront uniquement en Français dans votre situation.

Ensuite vient votre problème de choix de la langue par l’apprenant.
En supposant que vous diffusez vos contenus dans une hiérarchie similaire à :

|-module-A
|   |-en
|       `-index.html
|   |-es
|       `-index.html
|   `-fr
|       `-index.html
`-module-B
    |-en
        `-index.html
    |-es
        `-index.html
    `-fr
        `-index.html

Il y aurait plusieurs façons de faire cela :

  1. Développer ou faire développer un skin Opale Aurora dédié qui injecterait un widget de sélection de langue sur chaque page (ou seulement sur la page d’accueil) des modules Opale. Ce widget basculerait sur une autre URL, par exemple : ../es/index.html pour basculer vers la version en Espagnole
  2. Créer un site web générique avec Optim (par exemple) qui serait à la racine générale de votre serveur web et dans lequel vous scénarisez la présentation de liens « externes » vers vos différents modules et leur langues
1 « J'aime »

Bonjour,

L’organisation idéale coté édition, serait d’utiliser les mécanismes d’ateliers « calques de dérivation » pour gérer correctement vos traductions dans les autres langues. Cela vous offre une aide précieuse au suivi des évolutions de vos contenus dans la langue principale pour ne pas oublier des reports dans les versions traduites. Mais cette fonctionnalité exige l’utilisation d’un Scenari-server (non disponible dans la version « desktop »).

1 « J'aime »

Re bonjour

Un grand merci @sam pour la réponse qui permet en effet de gérer avec Opale, en demandant de mettre les mains au niveau technique.

@spi je prends aussi cette solution qui semble aller dans l’évolution car Opale n’est pas compatible avec les nouvelles versions de MacOS depuis la version 10.11. cette solution permet aussi de gagner du temps, il faut que je me penche dessus et donc migrer vers une version studio, ou alors vers un MyScenari via l’association peut être ?

De ce que je comprends elle ne demande pas d’intervention technique et reste 100% standard ?

Un grand merci à tous les deux pour votre temps sur ma demande.
Excellente journée

Oui avec la solution serveur de MyScenari (il faut être adhérent de l’association), vous disposerez de toutes ces fonctions en standard. Il vous faudra passer à Opale 3.9 au minimum, et de préférence passez directement à Opale 4.

Plus d’info sur les ateliers dérivés : Documentation utilisateur SCENARI 5.0

1 « J'aime »

Bonjour @spi
Un grand merci pour la doc c’est vraiment utile.
Sur l’offre MyScenari il n’est pas possible d’envoyer le Skin SunRise de ce que j’ai vu ?
C’est un grand changement au niveau interface va falloir s’y faire :stuck_out_tongue:

Excellente journée

Si, Le skin Sunrise est disponible, il est même installable directement depuis la présentation incluse dans le modèle Opale :

1 « J'aime »

Si vous êtes resté en Opale 3.9 dans MyScenari, il y a une anomalie dans ce lien de la présentation incluse dans le modèle Opale. Il faut le télécharger du site de téléchargement : OpaleSkinSunrise

1 « J'aime »

Bonjour @sam

Bien vu en effet c’était caché sous mon nez :stuck_out_tongue:
Un grand merci

Excellente journée

Bonjour @spi

J’ai suivi votre conseil de migrer direct de 3.7 a 4 mais comme l’a indiqué @sam il fallait l’installer depuis la page d’accueil de l’atelier. J’avais essayé de le télécharger comme on le fait sur un serveur indépendant, et là j’avais un message d’erreur :stuck_out_tongue:

Bon bah je n’ai plus qu’à me familiariser avec la nouvelle interface qui promet d’être plus agile :slight_smile:

Dernière question, il n’est tjr pas possible de synchroniser un atelier en ligne vers la version bureau via MyScenari ? et vice versa ? Cette fonctionnalité manque cruellement le dépôt off line

Excellente journée et un énorme merci à tous les 2 :slight_smile:

synchroniser un atelier en ligne vers la version bureau

Véritable serpent de mer depuis plus de 10 ans… A chaque fois que nous avions un contexte réel, le besoin s’est progressivement réduit pour devenir très occasionnel. Si vous basculez sur la version serveur de Scenari, vous nous direz dans 6 mois ou un an si l’absence de cette fonction vous semble toujours aussi important. En général il s’atténue…

Il faut garder en tête que toute logique de synchronisation est intrinsèquement porteur de complexité pour l’utilisateur lorsque des modifications concurrentes ont été effectuées. Toutes les solutions qui font croire que ces problèmes peuvent être résolus de façon transparente pour l’utilisateur ne font que masquer des décisions arbitraires et généralement problématiques pour la cohérence du contenu que l’utilisateur « paiera » ultérieurement. La fausse simplicité est un réel problème d’une telle fonctionnalité.

Aujourd’hui nous concentrons d’avantage nos réflexions sur les enjeux de « fédération » de contenus, à savoir le partage de contenus entre plusieurs utilisateurs ou organismes sans imposer pour autant un serveur centralisé. Si nous parvenons à avancer dans cette direction, indirectement, il pourra en partie améliorer le contexte de l’édition offline.

2 « J'aime »