So, I was in a Customer call the other week and I had another very interesting question "why are translated articles (when translated with the Localization Framework) always generated in a "draft" state?". This is a good question and the answer might not necessarily be what you may suspect, so let's delve into this topic and see what we can do about it to see if there is a way to automate it. Grab your favourite beverage and let's do this!
The challenge
When translating a KB article with the Localization Framework, it's primary objective is to facilitate the act of the source contents to be translated, then when the translation is "published" it's contributing a new child article to the KB that the source article came from. The default (aka ootb) behaviour here is such that it will follow the "publish" workflow defined at the KB level. So, if you are using the ootb "Instant Publish" workflow for your given KB, it would only be able to generate a "draft" status article because there are some mandatory values potentially needing to be populated - think "valid to" as an example.
This concept would apply to any language the source article is being translated to, and no matter which Localization Framework translation workflow you choose (including the "auto-translate" > "auto-publish" workflow). All outcomes will just end with a "draft" article being generated in the KB.
The main reason for this is not a limitation in the Localization Framework or even in Knowledge Management, it's because we essentially don't want to funnel all Customers into one way of doing things. Each Customer may (and often do) have different needs / requirements / use-cases when it comes to their KB's. Some want things to be super specific, some want things to be a bit more fluid, or some for various reasons (think regulatory) may need to prove all their necessary checks and balances (such as approvals) at every step of the way. Hence the ootb behaviour is this way, which means it is flexible the Knowledge Managers just need to define their process so that the logic can be built.
Above is a screenshot from our team's demo instance of some of the translations from my "What is spam?" demo article I often show being translated. As we know from our training, translated articles work in a "Parent" > "Child" relationship via the "parent" field. This logic exists so that each translated article has it's own KB number and allows each translation to have it's own versioning and therefore live it's own life-cycle because of the previously mentioned reasons.
It's not uncommon in some industries for certain regions / territories / languages to have to prove extra checks and balances for their translations. This could be (as mentioned) for regulatory reasons, Works Council reasons, Union agreement reasons, or Contractual reasons. There are many more, but these are just some high-level examples.
Technically can this be automated?
If we park the non-technical considerations for a moment, is there any technical way that we could nudge these newly "draft" generated articles into a "published" state? (to be clear, this would be for the scenarios that don't require such rigorous checks and balances) - the answer is yes.
Let's take the scenario where a fictitious customer is not obligated by any specific checks, balances etc, they validated the translations of the articles via the Localization Framework, so we know the translations are good / ok, and we just need to publish the article as is.
In this scenario, we could define a BR (Business Rule) on the [kb_knowledge] table where the Language (is not) English and the "status" is "draft" - this could be an example trigger for our business rule, but build one as per your needs.
- Ideally what we're saying with this trigger is that we're isolating an article that is not in the same basic concept as our source article type, therefore we're specifically trying to isolate only translated articles.
Then the logic we'd want to leverage actually already exists, and is from the UI action we use when we click "publish":
new global.KnowledgeUIAction().publish(current);If for what-ever reason you needed to "re-publish" an already existing article (rather than create a new one), you could use the following:
new KBKnowledge().republish(current);Remember you may need to factor in any mandatory fields such as "valid_to" - this code is just an example.
Conversely, if you had a scenario where you needed to un-publish (aka "retire") translated articles if the original English source changed, you could also create a BR where we trigger it when the current article's Language was English and it's state changed to "retired" (or what-ever other state is appropriate for you) and find all of the translated articles to un-publish:
var transArticleRetire = new GlideRecord("kb_knowledge");
transArticleRetire.addQuery('parent', current.sys_id);
transArticleRetire.addEncodedQuery('workflow_state!=retired^language!=en');
transArticleRetire.query();
while(transArticleRetire.next()){
new KBKnowledge().retireKnowledgeById(transArticleRetire.sys_id);
}
If you need to specifically "un-publish" the article rather than retire you can instead use the following line in the while loop:
new global.KnowledgeUIAction().unpublish(transArticleRetire);
What have we learned?
So, by reviewing how things are built ootb, we've learned that we can leverage the same mechanisms to help us build out our process requirements without needing anything particularly complicated and very minimal code, whilst also not modifying anything ootb. If this is a requirement you have, give this approach a go and see if it helps you. But please remember this is just a concept and each Customer may have their own very specific requirements so it may not necessarily suit you. You may need to make any such logic to only work on specific KB's rather than all - these could all be added to the logic in the conditions of any BR's you create.
And as usual, please like share and subscribe for more as it always helps
