Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make form title translatable #1640

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Conversation

avazirna
Copy link
Contributor

@avazirna avazirna commented Nov 6, 2024

Product Description

This PR makes it possible to set the form title according to the user's preferred language or by changing the language in the middle of a form session. Currently, the form title is derived from the form XML, which is defined by the active language when the form is saved, after a change or form creation.
In the video at the bottom of the description, it is possible to see that:

  • While the language of the user is Portuguese and most of the app content is shown in that language, when entering the form, the form title is in English;
  • Changing the language in app builder to Portuguese, making a change to the app and then creating a new build, results in the form title be presented in that language

Additionally, switching to another language in the middle of a form session doesn't affect the form title in any way.

Technical Summary

In terms of design decisions, two options were entertained during this work:

  1. Setting the title in the appropriate language when preparing response objects to be sent to the front-end;
  2. Maintaining the title in SerializingFormSession objects in the appropriate language;

Considering that the title in response objects is set based on SerializedFormSession objects, number 2 was the chosen option. This not only ensured fewer changes to the codebase, but it will also improve maintainability since changes to response classes are unlikely to affect this capability.

Safety Assurance

Safety story

Local tests were successful but one resource had to be update as with this change, the form title is retrieved from the translations.

Special deploy instructions

  • This PR can be deployed after merge with no further considerations.

Rollback instructions

  • This PR can be reverted after deploy with no further considerations.

Review

  • The set of people pinged as reviewers is appropriate for the level of risk of the change.
issue_form_title.mov

Copy link

codecov bot commented Nov 7, 2024

Codecov Report

Attention: Patch coverage is 95.23810% with 1 line in your changes missing coverage. Please review.

Project coverage is 70.27%. Comparing base (bb7cdbb) to head (6730246).

Files with missing lines Patch % Lines
...a/org/commcare/formplayer/session/FormSession.java 94.73% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1640      +/-   ##
============================================
+ Coverage     70.22%   70.27%   +0.05%     
- Complexity     2007     2014       +7     
============================================
  Files           254      254              
  Lines          7902     7919      +17     
  Branches        745      748       +3     
============================================
+ Hits           5549     5565      +16     
  Misses         2070     2070              
- Partials        283      284       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@avazirna avazirna marked this pull request as ready for review November 7, 2024 13:14
Copy link
Contributor

@shubham1g5 shubham1g5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add some unit tests that can demonstrate the title changing appropriately with the change of language.

@@ -51,7 +51,7 @@ public enum SubmitStatus {
@Column(name = "menu_session_id", updatable = false)
private String menuSessionId;

@Column(updatable = false)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a db schema change, does this break resuming into incomplete forms saved before this change ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should only impact DML statements, not the schema itself, but happy to test to make sure it doesn't break anything

Comment on lines 209 to 215
private String getFormTitleLocaleKey() {
if (commandId != null && !commandId.equals("")) {
String preparedCommandId = commandId.replace("-", "");
return "forms." + preparedCommandId;
}
return "";
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no guarantee in Xform spec that forms locale key will follow this format (it can be dianasour.m0f0 for exmaple). This should be using the same logic as we use to load the display text for menus instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shubham1g5 opted for a different approach, instead of storing the command ID to then convert it, I'm not storing the form title locale key.

@@ -108,7 +108,8 @@ public NewFormResponse getResponse(NewSessionRequestBean bean, String postUrl) t
bean.getRestoreAsCaseId(),
null,
formplayerRemoteInstanceFetcher,
bean.getWindowWidth()
bean.getWindowWidth(),
null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't need to be translated ?

Copy link
Contributor Author

@avazirna avazirna Nov 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because SessionFrame is null, I believe there is no commandId. But I'm not too familiar with this workflow, so happy to follow your lead. However, the fallback there is the title from FormDef, as it is right now.

@@ -141,6 +141,7 @@ public FormEntryResponseBean changeLocale(@RequestBody ChangeLocaleRequestBean c
changeLocaleBean.getSessionId());
FormSession formEntrySession = formSessionFactory.getFormSession(serializableFormSession, changeLocaleBean.getWindowWidth());
formEntrySession.changeLocale(changeLocaleBean.getLocale());
formEntrySession.updateFormTitle(changeLocaleBean.getLocale());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can reside inside formEntrySession.changeLocale itself.

@avazirna
Copy link
Contributor Author

We should add some unit tests that can demonstrate the title changing appropriately with the change of language.

@shubham1g5 I have incorporated this into existing localization tests: 2f1f467

@@ -108,7 +111,9 @@ public FormSession(SerializableFormSession session,

this.sandbox = restoreFactory.getSandbox();
this.windowWidth = windowWidth;

if (commCareSession != null && commCareSession.getCurrentEntry() != null) {
this.formTitleLocaleKey = commCareSession.getCurrentEntry().getText().getArgument();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think we need to usegetText().evaluate() which already seems to have locale support, so you might be able to use it's value directly without doing any further locale processing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HI @shubham1g5 I explored this approach before and revisited after seeing your comment. The issue is that it seems that getText().evaluate() fetches the values using the default locale and not the current language

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that takes into account whatever locale is set to the Localiser, saying as we use Localization.get() at other several places in the app to get the translation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but when we change language in the middle of a form session, it doesn't change the global locale, just the form-level locale. So calling getText().evaluate() continues to return the value in the default language, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants