Idea ID: 1671335

Localize Records

Status : Declined
over 2 years ago

Hi All,

Use Case:

Customer is offering services to several countries in different languages. The most of the service catalog (categories, service and offerings) and KM Documents are in different languages.

The way to localize them isn't very friendly for KM Documents, for service catalogue too,  due to "Content" field where contains html, hyperlinks, images bla bla bla. The curernt way/method is download a csv, edit it and load again from the studio. If you change the value of content, for example, you have to do it again.

On the other hand, i have upload the KM Documents migrated from SM and edit them in the current way, it's not easy, fast and confortable (see Article_to_es.csv) .


1-. Localize the records more friendly. Not using CSV file, directly in the SMAX.



  • Thank you for your idea. At this time, your idea hasn’t received enough community support and doesn’t align with our priorities so we are closing this idea. But we may review this again in the future. Thank you for your support and continue posting & voting on ideas to help make our products better.
  • Thanks . I changed the idea status from declined to waiting for votes (and clarified in the original post that knowing # of languages is separate)

  • Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team.

  • Hi ,

    1.-The export / import process is hard to manage it for KM Documents using CSV files when the implementation has several and usable languages and/or huge number of documents and the large content (content field) of themselves.

    Have you seen the CSV attached? It's the KM at the beginning: 240 documents with English, Spanish and Brazilian contents with "English" localized by default. (the most of them in Spanish or Brazilian). The customer has own translator groups but it's difficult setting a CSV with no errors that contains html or complex code to be imported succcessfully on SMAX

    It would be desirable modifing the content field trought the application and removing the export / import process even for all kind of records. On the other hand, it's awesome the way for translate the available values in lists at user options or labels of itselfs and/or drop-down fields.

    the idea would be having a language attribute (drop down list) near to content field, then smax will display the stored data for the language attribute selected on the drop-down list.  If there is no data for the language selected, it will display it in English (for example).

    This is for Production.

    2.- I will split the idea, but the KM / Service Catalogue / Tenant adminstrators have no idea about that attributes and/or records bla bla bla have been localized in some language. For example, defining a new and same offering for different languages: The admin has to log on the servie portal setting all languages for check the offering. Same for KM searches (Externally publish).

    I will be available to do a demo to you for better understanding.

  • Hi  - we can't have two ideas in the same posting. It's impossible to know what people are voting for, and quite possibly each unique ID has it's own status. Please separate your two bullets into two new ideas. 

    1-. Localize the records more friendly. Not using CSV file, directly in the SMAX.

    An in-tool ability to edit all languages  for offerings and articles makes some sense, especially so that this is consistent across localization use cases (with email templates, record field display labels,). However Catalog and KM are different by design. Catalog and KM consist of so much content, undergo frequent changes and additions, and tend to be localized for Self-Service purposes to many more languages. The only way to manage this efficiently is through an export/import process, often leveraging translation memory tools. Many customer use outside vendors for this. So the question is, is the preference for export/import vs. in tool impact by customer size? Is this for demonstration or POC reasons? Namely why doesn't this solution work. 

    2-. Knowing the languages that they have been localized.

    You say "He hasn't the way to know in how many languages the records have been lozalized. " Who? The system administrator? And how is this information used, or why/when is it needed. Explain the use case.