Hi @LSP we use multiple languages as well and I found that localization as much as you can on pages, menus, etc. is much easier than trying to separate everything by language. As for courses, we created unique codes that allow us to search for and add content to  single language catalogue (as courses cannot be localized at this time). Then, the catalogues are assigned to users...admittedly, our only wholly French group is in their own sub domain so it makes this a little easier however with the new Group options to create groups based on user language preference, this is much easier now to create those groups and align catalogues to these.

Hi @LSP 

We provide content in three different languages and each language group has its own landing page, menu and catalogs. This method was recommended by our Docebo contact during implementation and it has worked very well so far. One thing to consider, as @lrnlab has mentioned, is that it is now possible to create groups based on language preference. This wasn't available during our implementation, so we needed to create an additional field called "Content Language" to drive visibility for the different language groups. For more information about deploying courses in multiple languages, I would recommend the following thread.

https://community.docebo.com/let-s-talk-shop-42/deploying-courses-in-multiple-languages-186

@LSP good evening,

As Daniel pointed out above? Groups can now be driven by preferred language.

So I can tell you that you can now leverage a group that filters on the learners prefer language to drive a catalog widget to the appropriate language. 

• Catalogs can be filtered by language but only by the user, I can’t set them to pre-filter in the catalog widget (Pre-filtering would be a must). What happens when I set the course language? Do catalog widgets only show courses in a users chosen language?

As @Daniel was saying this is new ground…but you will find that groups and the catalog widget work well together to show you a specific catalog to a mapped group. To achieve this - You map your:

1. Preferred language to a group (let’s call it a “language group”)
2. content (via a catalog - map the language to a catalog - and for below let’s refer to them as a “language catalog”) to a language group
3. Ensure the page you put your widget on has the right permissions and visibility to all the language groups
4. create said catalog widget
5. Map the language catalogs to said widget
6. hold yer breath
7. test it by flicking on and off the a language preference and refresh the screen

last note - some people in the past have noted that dynamic groups may not be as dynamic as you may expect…with that dynamic mapping being a tricky subject…if you don’t autoenroll with these groups with enrollment rules? I think you will be golden…but please test test test…

Good morning….I hope all the theory works. We just went live in three countries with some of the ideas above….it is looking good...so far.

@dklinger - Please let us know how it goes! Also, how time-consuming was setting everything up?

How did it turn out? 
 

All my new courses will have 8 language subtitles and I’m making Spanish versions of some channels.

@dklinger and @lrodman - the approach went down pretty flawlessly.

We had one person that requested for an English version that we had on tap...and just redirected that person (by us enrolling him in the appropriate course).

Note - the volume was way low (this was with less then 200 targets) - so we encountered no issue with timing.

To ensure everything went down well? We also supported mapping a country to a branch. Each country had a preferred language - and so when we mapped, we mapped their preferred language as well.

I think you meant @Daniel  not @dklinger, @dklinger haha

How’d you do the language mapping - API and UAFs? Planning to try something similar.

Oh.... All via csv upload - a small target….supported that...

We use a deep link to the language dropdown in the Profile>Preferences area so users can toggle to their language choice from an image button on the homepage. Then we use the HTML widgets to assign different images/links for each language as hotbuttons on the homepage. If they toggle to Spanish then all Spanish localized images populate in the HTML widgets and are linked to the Spanish catalogs for example, same for each language. To keep the menu on the left also matching the content that surfaces with the UI language change, we have a group for each language that uses “Language” and “Branch” to assign them to a menu, it was a small amount of work to set up the groups and menus per language since I could duplicate and keep 90% of the pages in the menu and just swapped out the ones pointing to the language specific catalogs. That being said, we do have duplicated catalogs and courses for each language to ensure they are able to be individually surfaced. Currently we support 4 languages and are launching another 4 shortly. Hoping maybe Content Hub will get back on the roadmap and will make managing multiple languages a bit more streamlined but this set up is working great so far.

As ​​​@dklinger mentioned some groups are dynamic but some are asynchronous (I found this called out in the Docebo documentation too), if you use the default language field of a user to make a group and a user changes their language, the change is immediate. If you use an additional field for language that you’ve added to the platform for mapping, it is NOT immediate and the change will happen the next time the groups cycle (that was my experience testing these and I couldn’t pin down any kind of timeframe for when the asynchronous change would happen).

How do you create a separate landing page for a specific language group (i.e., I want my group of french speakers to land on a separate landing page in french)? I have this need as we have graphics with text that need to be translated and you can’t change the graphics across the different language options like you can with the Title and Subtitle, etc. text. We are also trying to avoid doing any HTML coding. 

@csaniewski you would need a field inherited from somewhere to put your French speakers into a group and assign that group to your French menu upon login if you want them to directly land on that designated menu/landing page. For example, if your user information is populated by Workday and you can pull in a field that specifies their language is French then you could create the group using this field. Otherwise, like in our case, we rely on them to change their language after they login by giving them a hot button that links to their Profile>Preferences tab where they can choose from the dropdown. This also gives them control to go back to English if they prefer also. 

This action can also be used with groups to bring them to a designated French menu (which is what we used to do) or, you can use the HTML widget and load your images separately per language like in the screenshot (Toggle off “Assign same content to all languages” and load your localized image for each language - this requires no HTML coding and can be done with the WYSIWYG). When your user chooses French then the designated images in your widgets for French surface, this allowed us to have one menu for 8 languages, and to link to different catalogs from the different images all within one widget.