Knowledge's new multi-lingual support: A brief look

In my last post I briefly described that in the Spring'11 release Salesforce updated knowledge with new multi-lingual support. While it is good in theory, in practice it presents some problems that are hard to work with.

One of the issues of the old knowledge version is in mass importing docs that may have changed or updated. This is due to the required unique URL Name field, and there being no way to update, only add as 'new'. To get around this in the old version, our edit team had to append -es or -de to the end of the field to allow

Example of our old update process:

• receive the zip file from Doc team (iOS_Ignition_ES_update2.zip) and unpack.
•  edit the CSV file to include:
•  datacategorygroup.products (lmiignitioniphone)
• a unique Doc_Group__c (igniosuges)
• and an edit to the URL name to prevent overlap/conflict with similar products (What-is-the-Host-ios-es2)
•  then re-zip files and add the articleImportSampleContent.properties file
•  In Salesforce, search for articles tagged with the same Doc_Group__c (igniosuges) and remove them from published docs due to URL name issue
•  In Saleforce, under Data Management > Import Articles, choose the new zip file and import.
•  After import, can then verify/review docs in draft and publish.

With the new knowledge multi-lingual support, we hoped it would solve this issue, but it does not, at least not for our needs.

When you follow their instructions for doing export, you'll find that they don't spell everything out, leaving you to assume some of the details, or having to run thought and figure it out by trial and error.

They also provide a 4min 'how-to' video, which walks you though the process of setting up the new multi-lingual support and the two ways they offer for translations, but it is more of an overview, and misses a few key issues with the import, mainly that the URL Name field needs to be Unique so it cant be the same as the original Article.

Then when your trying to do an export, besides being very cumbersome, the format of the export itself is not very usable, It would be nice to be able to export to .csv since you can import with it, but instead it gives you a zip of a bunch of folders with an individual document in each. If you try to export form the translation work bench, on the page where you choose what format you wish to export in, it says:

You can export three kinds of text

* Source - Produces one .csv file that contains all of the text that is translatable

* Untranslated - Produces a set of files, by language, with text that is not yet translated

* Bilingual - Produces a set of files by language that contain all of the text that is translatable

BUT the source does NOT produce a .csv file, it is instead a .stf file, which i am sure is useful for the correct program, but not what we need, or expected from the above instructions.

Overall i still think that knowledge's new multi-lingual features is a step in the right direction. It is definitely good if you are doing in-house editing, BUT I think that knowledge, in general, has a ways to go if they want orgs with more than 500 articles to utilize it efficiently.