[Clarification] on Translation Editor for Forms Project

Community GSoC
1

Hello OpenMRS community :waving_hand:,

My name is Souvenir Turinumugisha, and I’m currently pursuing a Computer Science major at Northwestern University. I have a strong passion for web development and have built several web applications over the past two years. I’m a full-stack developer (Frontend Heavy), particularly experienced in building responsive and user-friendly web interfaces. My technical toolkit includes modern technologies such as React, Angular, Tailwind CSS, and TypeScript on the frontend, alongside Node.js, Express, and Spring Boot on the backend. I also work with databases like PostgreSQL and MongoDB, and I’m comfortable with tools like Git, GitHub, GitLab, and testing frameworks like Cypress.

I’m incredibly excited to apply for Google Summer of Code 2025 and contribute to OpenMRS’s mission to save lives through code. I’m particularly drawn to the “Translation Editor for Forms” project. Over the past few days, I’ve been closely reviewing the project description and documentation and interacting with the project UI. I’d like to summarize my current understanding of the project after reading the project description and get corrected where I might be wrong to make sure I get everything right as I work on my proposal.

My Current Understanding of the project:

:white_check_mark: Current translation workflow (before this project):

  • Form translations are created as JSON files and placed in Initializer folders.

  • These translations are loaded at startup and saved to the database as formResources linked to each form.

  • Updates require editing config files and restarting the server which is not ideal for non-technical users.

:white_check_mark: Goals of this project:

  • Introduce a separate Translation Editor UI for managing multi-language translations.

  • Let users view and edit all translatable strings in a form schema (question labels, answers, etc.).

  • Preview the form in any selected language using the form renderer.

  • Allow users to download translation JSON files for each language (for manual import via Initializer).

  • Not save translations to the backend or database — this is explicitly out of scope.

:white_check_mark: How translations might be temporarily stored during editing (my current thinking): Since we’re not saving to the backend, I’m assuming we’ll keep translation data:

  • In memory (within React state), or

  • Optionally in localStorage or IndexedDB for session persistence

That way, when users switch between languages or return to edit later, the editor can repopulate the translations they’ve worked on — without losing progress. This is my current assumption and I would like to get corrected if I’m wrong.

:white_check_mark: Previewing the form in another language:

  • The form renderer can receive the entire formJson (including a translations object) and render the form in the selected language.

  • The language selection here should apply to the form only, not the overall app UI — unless the global language is also changed via the navbar.

:white_check_mark: Download behavior:

  • The final translations should be exportable as JSON files, with the correct naming convention for use with Initializer.

The ask:

I’d really appreciate it if @Nethmi or anyone else who understand this project better could help confirm if:

  • My interpretation of how form and translation data is managed (especially during editing) is aligned with what is anticipated for this project

  • The idea of storing unsaved translation progress in react state (or similar) fits within what’s expected or recommended

  • There are any edge cases I might be missing, especially around previewing, switching languages mid-session, or exporting translations

I’m looking forward to diving deeper into the form engine and builder source code, and I’m excited to begin drafting my GSoC proposal based on this understanding.

Best regards, Souvenir Turinumugisha

1 Like
2

Hello @Souvenir, :waving_hand:

You are most welcome to OpenMRS community. It’s refreshing to see your excitement as well as your comprehension of the Translation Editor for Forms project. You have explained the current workflow, goals, and possible methodology incredibly well.

As you pointed out, the project does indeed focus on providing a rather elegant interface for managing translations without having to perform any backend work. It is quite useful to temporarily save translation data using React state or localStorage because it mitigates the risk of losing data during a mid-session switch, or an unexpected page reload. If however, there is a lot of translation data that needs to be handled, IndexedDB could also be a good option.

For previewing, your assumption is rational as well — the renderer of the form will depend on the translation object to render the form in the preferred language. And yes, the translation language set will change only for the form and not for the rest of the application UI unless it is specifically taken care of.

4

It is not “explicitly out of scope”, if there is time remaining, you are more than welcome to develop this feature.

How translations might be temporarily stored during editing (my current thinking): Since we’re not saving to the backend, I’m assuming we’ll keep translation data:

  • In memory (within React state), or
  • Optionally in localStorage or IndexedDB for session persistence

Yes, but if a form already has translations for a certain language saved in the backend, this should be picked up by the editor. And it would be good for a user to be able to import translations from a JSON file.

The final translations should be exportable as JSON files, with the correct naming convention for use with Initializer.

Yes, not just the naming convention but also the correct JSON format.

1 Like
5

Thank so much @atulyadav745

6

Thanks @nethmi for clarifying on this

7

Noted! @nethmi can you also confirm if this is true or not:

  1. We should initially load the form translations from backend and populate the editor with that (before they even choose the language) and in the languages dropdown, select that language by default! is this right?

  2. Users should be able to import translations for a selected language. Should we add validations for the json to be uploaded to make sure it’s a translations file?

8
  1. We should initially load the form translations from backend and populate the editor with that (before they even choose the language) and in the languages dropdown, select that language by default! is this right?

That makes sense to me.

  1. Users should be able to import translations for a selected language. Should we add validations for the json to be uploaded to make sure it’s a translations file?

We should show an error if we can’t parse an updated file and load the translations, yes.

1 Like