Skip to main content

Having done several LMS implementations, I found that keeping track of what options, configurations, settings, etc. an be challenging. There are so many options and these can require updating, changes and rework depending on changing business needs and system updates.

In order to keep things in check and also allow others who may share these type of responsibilities in your team(s), a Configuration Log becomes an indispensable part of your project artifacts, and beyond.

This is especially true when managing sub-domains who can each have their own versions of settings and configurations. We also track original (or default) values and the new values including the reason or rationale for any updates (this helps a lot in a few years time when you ask, “...how come we set this up like this?”

Another area where this comes in very handy is for all Localization changes. If you’ve worked on localization at all, you that once you change the label format’s original value, it can sometime be difficult to find it again. There are many labels that have the same text but are used in very specific places. Whenever this type of change is made, we capture the label type, module name, original value, new value and also track the site the change was made on (sometimes we are just easing things in our sandbox and don't actually make the change in production so this helps to know where changes have been made).

My localization log has these tabs (sections):

  • Module
  • Key
  • Original text
  • New text
  • Reason for change
  • Site (where the change was applied)
  • Change Date (for each site)
  • Change competed by

To get started, I usually browse though the entire system and track what areas we’ll need to work on. For example, on the Advanced Settings app, there are many tabs that each have their own set of possibilities. I have a spreadsheet to track all the fields and their values. 

My log has these tabs (to name a few)

  • Advanced Settings
  • Sub domains
  • Enrollment rules
  • White Labelling
  • External Training
  • Additional Fields (on each for users, courses, enrollment)
  • Test accounts (keep track of who owns what test accounts)
  • Categories
  • Catalogues

Here are a couple examples of what this can look like:

Localization log
Advanced Settings tab

I hope this can be useful for you...if you have any questions or would more information, please let me know.

That is an awesome looking log by what I can see….got a question, can you share it here? Maybe wipe out most of the data and attach it?

This is awesome. Thank you @lrnlab! I second @gcrawford88’s request. I’d love to check out a blank sample log if you’d be willing to share! I’ve used a similar process in the past solely for the localization tool, but it’s brilliant to keep track of some of the other settings that you pointed out.

So, your Localization Tool log includes the column “Site (where the change was applied)“ - So, in an Extended Enterprise edition, can you apply changes to a single subportal?

I made changes from within that portal but they still showed up everywhere and I couldn’t find a setting where to limit it to the site I was working in

So, your Localization Tool log includes the column “Site (where the change was applied)“ - So, in an Extended Enterprise edition, can you apply changes to a single subportal?

I made changes from within that portal but they still showed up everywhere and I couldn’t find a setting where to limit it to the site I was working in

no, it’s just to log changes on Sandbox vs. Production

This is awesome. Thank you @lrnlab! I second @gcrawford88’s request. I’d love to check out a blank sample log if you’d be willing to share! I’ve used a similar process in the past solely for the localization tool, but it’s brilliant to keep track of some of the other settings that you pointed out.

@Adam Ballhaussen Think I started to blank out a version a while back but just haven't had a bunch of time to do that...when I do I can certainly share.

Hey @LSP, the Localization Tool cannot be configured on a per-domain basis for platforms with Extended Enterprise activated. Changes to each language in the Localization Tool apply to all domains.

 

@danielherrerasmith recently shared an idea in the community to offer this functionality. I encourage you to upvote the idea and add any additional information that relates to your use case.

 

 

You can learn more about Docebo’s Localization Tool in the Managing the Localization Tool & Platform Languages article

@Adam Ballhaussen Thanks for the response. Can the default language be changed on a per-domain basis? As in, could it be a work-around to export English and re-import it as another language. Then set one domain to the “new” language and change things there?

Hi @LSP, this is a really interesting idea. I honestly have never heard of anyone trying this, but there’s a chance that it could work.

 

If I understand you correctly, you’re proposing to use a language in the platform that you don’t need for your learners, let’s say Latvian, to import a set of translations that translate the Latvian keys to English translations, and to then change the default language of a specific installation to this new Latvian / English language. Is that correct?

@Adam Ballhaussen Yes, that’s pretty much the idea. My hope would be that I could export English and import the whole xlf into Latvian so it replaces all Latvian translations and it’s a copy of English.

Or even better, I’d like to create a whole new “language” or change any instance of the word “Latvian” to “English” as well so I could call it “English adapted” or whatever so it’s not odd for learners if they have to choose between “Latvian” and French as their language in our (soon-to-be) 2-language portal. But at least with English there are two versions to choose from :sweat_smile:

@LSP I see exactly what you’re going for. I honestly can’t tell you definitively whether or not this would work, but I can anticipate a number of concerns with this approach. My biggest concern is that you’d run into issues any time Docebo updates our language keys or adds keys for other languages. This might result in there being non-English words in your “English adapted” platform.

 

You might be able to alleviate some of that concern by using English UK as your second language. You can change the name that will appear for a certain language by selecting Edit next to a language in the Localization Tool and updating the Description. You’ll need to refresh your platform to see the changes take effect. 

 

Please let me know what the results are if you end up testing this! You’ve piqued my curiosity.

We probably won’t test it for this project, but maybe there’ll be opportunity in the future. I’m curious to see what happens too :grin:

Reply


Terms & ConditionsCookie settings