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

Internationalization - alert messages is not toggling with language selection #5202

Closed
JayanthyChengan opened this issue Oct 16, 2018 · 18 comments

Comments

@JayanthyChengan
Copy link
Contributor

The alert info/warning/success messages remains English , and doesn't toggle with Language selection .

image

@landreev
Copy link
Contributor

harvesting clients page, with the fixes applied:
screen shot 2019-01-23 at 1 39 26 pm

@landreev
Copy link
Contributor

landreev commented Jan 23, 2019

@scolapasta - if you're online, please take take a look and let me know what you think...

In addition to the above, I'm wondering if we should refactor things a little; specifically, I'm not sure we even need this new dedicated DataverseLocaleBean... As it is, it does 2 things:

  • tracks the currently selected locale throughout the user's session. But does it need a bean of its own? - We already have a session-scoped bean: the actual session, DataverseSession. Any reason not to handle the locale setting there? (anything I'm missing?)

  • the other part is the methods that are not specific to any individual sessions - useLocale() that decides if we need the language dropdown (all it does, it checks if there's more than 1 language configured in the settings) and the methods that populate it if so. I feel it would make more sense to move these into the SettingsWrapper.

Let me know.

@landreev
Copy link
Contributor

landreev commented Jan 23, 2019

Also - probably out of scope - what about all the text messages in the API responses; are we ok with them always being in the locale that is the default for the specific Dataverse installation? (i.e., the configured locale on the server running the application).

(one alternative would be to default to that, but then also try to honor the "Accept-Language" header in the HTTP request, if possible...)

@landreev
Copy link
Contributor

(the current solution appears to be working well; I'll sleep on it over the weekend and make a PR before next week)

@landreev
Copy link
Contributor

The code in the PR has been refactored as outlined above: the session-scoped bean DataverseLocaleBean has been removed; its functionality split between DataverseSession and SettingsWrapper.

@djbrooke
Copy link
Contributor

Assigning to @matthew-a-dunlap because of his pre-volunteering in standup this morning :)

@landreev landreev removed their assignment Jan 30, 2019
@scolapasta
Copy link
Contributor

@landreev The only thought I had for not including on every xhtml would be to have every page bean extend from a base bean that had a default init method that does this and then calls a the page specific init method (renamed to _init or something else). Would still require making lots of changes now, but would be more maintainable if we had any other such changes.

Probably not worth the effort right now, but something to consider for the future.

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

No branches or pull requests

8 participants