-
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 language slug available via session metadata #1630
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
String appLang = locale; | ||
if (locale == null) { | ||
String[] locales = Localization.getGlobalLocalizerAdvanced().getAvailableLocales(); | ||
appLang = locales[locales.length-1]; |
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 grabs the last locale created? is that always right one?
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.
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.
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 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(); |
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.
How does HQ get to know of current locale to send here ?
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.
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.
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.
did you mean HQ was already sending the current locale in the request body without us having to make a corresponding HQ change here ?
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 I believe so!
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]; | ||
} | ||
} |
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.
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.
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 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 :(
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.
…the simpler Localization.getCurrentLocale()
@@ -22,6 +22,7 @@ public class AuthenticatedRequestBean { | |||
private int timezoneOffsetMillis = -1; | |||
private String timezoneFromBrowser = null; | |||
private String windowWidth; | |||
private String locale; |
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 seem like it's getting used anymore, think we can remove all bean model changes with the updated implementation.
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 is solely so that the test can pass!
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.
nevermind! this was removed
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 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); |
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.
How is this working given sessionNavigationBean
does no longer have setLocale
method ?
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. |
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 anavigateSessionWithAuth
request. Because this process continually recreates the context object, its the ideal entry point to insert this value which will be propagated to the eventualgenerateRoot
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
Rollback instructions
Review