By Svetlana Milter and Traci Farrell. Multi-lingual functionality is essential when creating digital products for diverse populations.
The UCSF SOM Tech recently built a patient-centered virtual community that supports three different languages for Asian Americans newly diagnosed with cancer. The work was done for the Patient COUNTS research study, which involves a web-based portal that allows patients to share symptoms, patient-reported outcomes, treatment experiences, and access resources so they can have the best possible patient care experience.
This translation project – our first – taught us a lot. It was always intended as a learning project, and we encountered a variety of problems. We picked Salesforce Community as our solution because it supported multi-lingual translation and Qualtrics integration, and our previous experience building Salesforce products gave us confidence in our choice. However, we did not evaluate implementation steps or fully understand the complexities of the Salesforce translation module, which led to many challenges.
While Drupal is a prominent web development system and widely used at UCSF, we didn’t use or consider it. Multi-lingual functionality was just one of several requirements for this project, and Salesforce’s Health Cloud care navigation functionality was better suited to our application-like product versus Drupal’s functional websites.
It was only after completing the project that we did a retroactive market scan to evaluate other multi-lingual options.
Pain Points and Lessons Learned
After project completion, our team held a retrospective to identify what worked, what didn’t work, and how to improve our future processes. We encountered technology, translation, and knowledge problems and hope our experience is useful to others. Here are a few of our biggest lessons learned:
- Translation took much longer than expected. Ongoing, continuous content creation and edits led to endless and painstaking translation across multiple languages. Because we didn’t finalize the English content first, it felt like we were translating against a moving target. Lock your source content before you start working on the translation.
- Engage the right resources. We would have benefitted from hiring a dedicated content/translation resource to manage the editorial process. We often had developers, analysts, and other available resources working on translation. Not only did this take resources away from other areas, but it also made it difficult to validate the translation without the right skillsets.
- The technology was harder than anticipated. We experimented with Salesforce Health Cloud technology, which was new to us, still in beta, and released during the course of our project. We tried different features, but they proved either unnecessary or needlessly complicated and clunky.
- The technology conflicted with the application code. The mobile language auto-translation browser detection feature interfered with the Patient COUNTS code, which resulted in having to redesign the application.
Retroactive Market Scan
We investigated other multi-lingual options retroactively and found they all had similar functionalities and price points. We did a deep dive into Salesforce Community, Drupal, and Microsoft SharePoint, which are available and used across UCSF.
If you pursue machine translation options, rather than manual human translation, keep in mind the translation might not be as accurate. Salesforce has a machine translation option via Google Translate, but we decided not to use it because of accuracy concerns. The cloud platform services use translation application programming interfaces (APIs), which offer real-time translation (e.g., Azure, Google Translate, Amazon Translate).
Beyond supporting multi-lingual capabilities, Salesforce Community also allows Qualtrics integration, which we used to incorporate translated surveys in a seamless flow in user-selected languages. Within the Salesforce site builder, the content is written, formatted, and edited in a rich content editor with drag and drop features to structure the pages. The default language, English in our case, forms a core page from which each additional language is translated and replicated across separate pages.
Without native speakers on the project, our engineering team often worked blindly with text they didn’t understand. Revising a sentence on the English page was easy enough but near impossible on the Chinese and Vietnamese pages. We would have benefitted from creating a content map or easily traceable repository to understand where corresponding pieces were in the languages we didn’t speak.
Salesforce provides a translation workbench that allows you to export your default/English content in a flat file, which can be translated into other languages and then reimported or translated directly on the page. This creates one master export file with all languages consolidated, so you don’t need to redevelop the traceability as we did. While useful, the workbench is best suited for use and maintenance by a single person rather than a team of people.
Drupal’s language function is a browser add-on, which, at times, seems to create problems when the browser configurations and translated sites collided. One of the biggest positive differences between Salesforce and Drupal is that Drupal respects browser settings, so if you set Chrome or Safari to display in a specific language, the switch will happen automatically.
We also discovered a less technical translation solution via UCSF’s Interpreting Services. We did not use this service, but for something as crucial and complex as patient care, manual human translation services are always a safe choice to consider.
What’s Next
As a learning exercise, there was a lot stacked against us during this project. We have no immediate plans to continue exploring multi-lingual tools or building our skills in this area. However, we learned an immense amount, have a better understanding of the translation landscape, and know what each technology platform can deliver. We’re prepared if we decide to work on translation projects in the future.
Svetlana Milter is business solutions architect, School of Medicine Technology Services, UC San Francisco.
Traci Farrell is communications lead, School of Medicine Technology Services, UC San Francisco.