-
Notifications
You must be signed in to change notification settings - Fork 8
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
base: master
Are you sure you want to change the base?
Conversation
This is to be used to retrieve the translation
Codecov ReportAttention: Patch coverage is
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. |
There was a problem hiding this 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) |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
private String getFormTitleLocaleKey() { | ||
if (commandId != null && !commandId.equals("")) { | ||
String preparedCommandId = commandId.replace("-", ""); | ||
return "forms." + preparedCommandId; | ||
} | ||
return ""; | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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.
@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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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:
Portuguese
and most of the app content is shown in that language, when entering the form, the form title is inEnglish
;Portuguese
, making a change to the app and then creating a new build, results in the form title be presented in that languageAdditionally, 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:
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
Rollback instructions
Review
issue_form_title.mov