Many clients operate globally and need their forms in multiple languages. With the current platform, each language needs its own form. Some users would like a single instance to contain multiple languages.
The first thing I was told was that this feature would not be a tool for managing translation statuses as it doesn’t currently align with our business model. The expectation is that translators will use external translation tools and then provide the finished files to our Citizen Developer creating the form. The corresponding translation string will be mapped through the unique ID that each question, sections and pages have. I did have concerns about the unique ID getting lost in a process external to ours, and was waiting on confirmation from SMEs.
Diving into this a little deeper there were 3 high-level things I need to think about in my designs; how to handle static assets, alerts about translation problems and questions that show or hide depending on the language.
Handling Static Assets
First, some questions rely on assets (images and pdfs) where text can’t be swapped. I’ve come up with 3 solutions for this problem that I need to present to all dev teams to better understand viability. Options 1 and 2 will likely run into problems with the platform’s limits for the number of images. These solutions are listed from most to least effort for dev teams.
- Uploads different versions under the main file. In the form, the user picks the main file and the product handles the mapping for language type. This solution behaves the most like the handling for translations.
- Let the users pick the file for each language (or include the filename in the translation file). These files would likely be individual uploads.
- Only one file is provided for relevant question types. Users could upload files with the different languages included there. This solution involves more work for the mobile user to find the correct language.
Errors for Translations
As we aren't looking to have our product be a translation tool, the PO said we would not track translations. Thinking on this more I feel we should be alerting our Citizen Developers about missing translations to prevent a poor experience for end users. Maybe even out-of-date as well.
The problem is that translations will likely be handled externally and our clients will be blocked to solve the error and deploy their forms. We could allow the Citizen Developer to dismiss warnings related to translations – but the platform doesn’t support dismissals. We would need to spend more time planning behaviours around dismissal messages (per user, for how long etc.) before implementing such a solution.
I came up with two alternate solution to handle missing solutions. One is to allow users to set up fallback languages for the form to use for missing translations. The second would be to allow users to deploy the languages that are up to date: the form would be in asynchronous states of deployment. This whole area will likely not be explored further until the first version of the solution is launched and we get input from a wider amount of users.
Show and Hide Questions
While showing preliminary work to the PO, I was told that some users want to show and hide questions depending on the language – this is tied to region requirements. After the meeting, I worked on 2 solutions for how a user could complete this. (Direct on the question or with conditional logic).
The information the PO shared also meant that the UX leads plans for how to show the correct language for a form was no longer viable. The initial plan was default the form language to a phone’s chosen locale. However, this could mean that users fill in irrelevant questions or missing important question for their region.
To move forward with a decision on both matters, I felt it would be best to speak with Users to learn more about their process.
Wrapping it Up
I was really looking forward to seeing this solution come together but that sadly didn’t happen before I left the company. I hope my leg work on the solution thus far put the company in a good position to move forward. The devs were really eager to hear more and review the designs. I wish I got to complete user testing to collect insights about this solution. In particular, which of the options I planned would users have felt best met their needs?