Interactive Builder for Form Translations within the Form Builder (Interactive Translation Builder?)

4 Must-Do’s

1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves).

2. User Stories: Have you clearly written at least 3 user stories and use cases?

3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here)

4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement?

Optional/Encouraged

Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!)

Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can?

Later but should do

QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)?

Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those?

This checklist was inspired by this article. Additional Business Analyst Resources here.

Problem Statement

Right now, in order to add translations to a form, the way to do this to add it to a configuration folder that can be picked up by Iniz. This is annoying because

You’d need a developer’s help to know what to do and where to do it
The JSON file format is quite different from that of a form, so its not very intuitive for a non-techy person to do
There’s no a dynamic and user-friendly way to do it

Project Size

Large

Why we need it?

In the day and age of content packages, this would be a method for people to re-use forms but customize it to their language in a user-friendly way.

Project Idea

Similar to the interactive builder, a UI that would enable users to add the translations for a form for any language.

Here’s a (very high level) flow of how that might look like:

A separate UI editor(from the interactive builder) to manage translations
Preview the form in selected language and add language options
Adding the translation strings

Implementation

A UI editor needs to be implemented to manage the translation strings for each question
1. This can get tricky because we also need to consider the translations for answers
The JSON editor needs to contain the translations within the JSON to support dynamically viewing the translations
We need to figure out how to preview a form in a certain language
Once a user clicks Save Translations the translation files should be saved in the backend as a form resource.
Users should be able to download the translation resource file (check the reference materials to see what the file format should be) for a specific language

Reference materials

An example form translation file in English - https://github.com/openmrs/openmrs-distro-referenceapplication/blob/main/distro/configuration/ampathformstranslations/Ampath%20POC%20adult%20return%20visit%20form_translations_en-core_demo.json
An example form translation in French - https://github.com/openmrs/openmrs-distro-referenceapplication/blob/main/distro/configuration/ampathformstranslations/Ampath%20POC%20adult%20return%20visit%20form_translations_fr-core_demo.json
The original form itself - https://github.com/openmrs/openmrs-distro-referenceapplication/blob/main/distro/configuration/ampathforms/ampath_poc_adult_return_visit_form_v1.6_core-demo.json

Projects