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 language slug available via session metadata #1630

Merged
merged 10 commits into from
Oct 23, 2024

Conversation

minhaminha
Copy link
Contributor

@minhaminha minhaminha commented Oct 8, 2024

Product Description

Users will now be able to reference the current language slug (i.e. 'en', 'es', etc.) on the screen by referencing instance('commcaresession')/session/context/applanguage

Technical Summary

Jira Ticket

Associated commcare-core PR

This is the formplayer side of the changes. All this code does is ensures that EntityScreenContext has the right locale (a string) value provided on initialization and a null value for any instance that's not directly related to the workflow kicked off by a navigateSessionWithAuth request. Because this process continually recreates the context object, its the ideal entry point to insert this value which will be propagated to the eventual generateRoot function (actual code surrounding this part and further explanation will be in the commcare-core PR).

To be complete this PR also covers an instance of ExternalDataInstance initialization that will now optionally accept a locale argument.

Safety Assurance

Safety story

This shouldn't impact existing data since the EntityScreenContext object is constantly being recreated with updated information and most of the time the locale value will be null.

QA Plan

No plans for QA but will have delivery (who request this feature) do some testing to ensure it's doing what they want.

Special deploy instructions

  • This PR can be deployed after merge with no further considerations. (Of course the commcare-core PR will be merged first and this PR updated with those changes before merging/deploying).

Rollback instructions

  • This PR can be reverted after deploy with no further considerations. (Ideally should be rolled back with attached commcare-core PR?)

Review

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

Copy link

codecov bot commented Oct 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.22%. Comparing base (c069207) to head (6b0ad02).
Report is 27 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1630      +/-   ##
============================================
+ Coverage     70.16%   70.22%   +0.05%     
- Complexity     1999     2003       +4     
============================================
  Files           254      254              
  Lines          7881     7899      +18     
  Branches        741      742       +1     
============================================
+ Hits           5530     5547      +17     
- Misses         2069     2070       +1     
  Partials        282      282              

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

String appLang = locale;
if (locale == null) {
String[] locales = Localization.getGlobalLocalizerAdvanced().getAvailableLocales();
appLang = locales[locales.length-1];
Copy link
Contributor

Choose a reason for hiding this comment

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

this grabs the last locale created? is that always right one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks so much for pointing this out, totally forgot to go back to this. The locales list is always as follows: ['default' (like literally just a string called default), , <all other slugs in order the were added]. The locales.length-1 was previously a placeholder and wouldn't have worked if there were more than one languages. Added a similar comment in the code too to avoid confusion.

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.

This will need test coverage before the merge, you can look at the tests added in #1596 for an example.

@@ -165,6 +167,7 @@ public EntityDetailListResponse getDetails(@RequestBody SessionNavigationBean se
public BaseResponseBean navigateSessionWithAuth(@RequestBody SessionNavigationBean sessionNavigationBean,
@CookieValue(Constants.POSTGRES_DJANGO_SESSION_ID) String authToken,
HttpServletRequest request) throws Exception {
String locale = sessionNavigationBean.getLocale();
Copy link
Contributor

Choose a reason for hiding this comment

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

How does HQ get to know of current locale to send here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Honestly not too sure! I just assumed all navigation request included the locale in the request body which gets set when initializing the sessionNavigationBean. Happy to be told otherwise but it's been accurately giving me the correct locale so far.

Copy link
Contributor

Choose a reason for hiding this comment

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

did you mean HQ was already sending the current locale in the request body without us having to make a corresponding HQ change here ?

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 I believe so!

Comment on lines 68 to 76
if (appLang == null || !Arrays.asList(locales).contains(appLang)) {
// the ordering is always ['default', <true default slug>, <all other slugs in order they were added>]
if (locales.length >= 2) {
appLang = locales[1];
} else {
// to pass tests
appLang = locales[0];
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

My read of the code here is you are trying to get the current selected locale ? If so, think we can use Localization.getCurrentLocale() directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wish I had known about this function sooner because this is doing exactly what I was looking to do from the start, without having to do all the unnecessary steps of passing the locale to the root generator function... I might end up reverting the commcare-core PR :(

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -22,6 +22,7 @@ public class AuthenticatedRequestBean {
private int timezoneOffsetMillis = -1;
private String timezoneFromBrowser = null;
private String windowWidth;
private String locale;
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 seem like it's getting used anymore, think we can remove all bean model changes with the updated implementation.

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 is solely so that the test can pass!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

nevermind! this was removed

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.

I don't think the tests are set up correctly. Since we are no longer dependent on locale being passed from the request body or request bean , locale should no longer be assigned to the bean for testing. Also we should add additional testing that incorporates changing of locale in between a test and check whether the xpath expression returns new changed locale correctly.

Also double confirming that we have tested the new implementation on an app somewhere ?

@@ -828,6 +828,7 @@ <T> T sessionNavigateWithSelectedValues(String[] selections, String testName, St
sessionNavigationBean.setSelections(selections);
sessionNavigationBean.setSelectedValues(selectedValues);
sessionNavigationBean.setWindowWidth(windowWidth);
sessionNavigationBean.setLocale(locale);
Copy link
Contributor

Choose a reason for hiding this comment

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

How is this working given sessionNavigationBean does no longer have setLocale method ?

@minhaminha
Copy link
Contributor Author

minhaminha commented Oct 23, 2024

After some discussion, because delivery wants this feature to be usable ASAP, Shubham and I agreed to add (proper) test coverage for this change in a separate PR. I'll link it back to this one once it's up.

@minhaminha minhaminha merged commit 6072202 into master Oct 23, 2024
6 checks passed
@minhaminha minhaminha deleted the ml/lang-slug-metadata branch October 23, 2024 18:59
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.

3 participants