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

Bug 1958080: CONSOLE-2535: Internationalize login page #71

Merged
merged 2 commits into from
May 7, 2021

Conversation

jhadvig
Copy link
Member

@jhadvig jhadvig commented Mar 25, 2021

@sg00dwin the locales will be available in locales.go where all the locales will be living in a form of key-value struct. They are hardcoded into the oauth-server since there is just a handful of them. We need to update all the login related templates so they contain the go template macros.

Had to add golang.org/x/text/language package to get helpers for parsing the Accept-Language header.

/assign @stlaz

@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 25, 2021
sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request Mar 29, 2021
@sg00dwin
Copy link
Member

@jhadvig
Related pr openshift/oauth-templates#15

sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request Mar 31, 2021
sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request Mar 31, 2021
sg00dwin added a commit to sg00dwin/cluster-authentication-operator that referenced this pull request Mar 31, 2021
@jhadvig jhadvig force-pushed the CONSOLE-2535 branch 2 times, most recently from 5efca2a to 6c96a14 Compare April 6, 2021 09:03
@jhadvig jhadvig changed the title [WIP] CONSOLE-2535: Internationalize login page CONSOLE-2535: Internationalize login page Apr 6, 2021
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 6, 2021
@jhadvig
Copy link
Member Author

jhadvig commented Apr 6, 2021

@stlaz we are ready for review. PTAL

@jhadvig
Copy link
Member Author

jhadvig commented Apr 7, 2021

/retest

Copy link
Contributor

@stlaz stlaz left a comment

Choose a reason for hiding this comment

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

Our repositories require enhancements in order to merge new features. Can you please link an enhancement describing this change? It would make it simpler to reason about the alternatives to just getting "Accept-Language" header and about the timing of the translations.

}

var locale_en = map[string]string{
"": "",
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the empty string key for?

switch langBase {
case language.English.String():
return locale_en
// Uncomment once given locale is available
Copy link
Contributor

Choose a reason for hiding this comment

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

When is that going to be?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thats up to translations team that is providing those.
@sg00dwin any estimations ?

Copy link

Choose a reason for hiding this comment

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

Full-time translators typically use specialized file formats/tools/editors, a repository of previously-translated strings, and the like. How is this going to interoperate with such workflows?

Is this really such a unique and special case that asking translators to provide Go patches, or setting up a special process to manually turn contributed translations into Go patches, is worthwhile and practical?

Copy link
Member

Choose a reason for hiding this comment

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

@mtrmac We have these tools in place for the main console repo. We thought that would be overkill here for a handful of messages that rarely change. We were planning to include whatever strings we need with the other console strings, and the console team would manage patching them when needed.

Copy link
Member

Choose a reason for hiding this comment

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

Thats up to translations team that is providing those.
@sg00dwin any estimations ?

The translation team doesn't provide estimated turn around times. Still waiting.

Copy link
Member

Choose a reason for hiding this comment

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

Translated strings are now included for each language.


func getLocale(langBase string) map[string]string {
switch langBase {
case language.English.String():
Copy link
Contributor

Choose a reason for hiding this comment

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

How do I know this works?

Copy link
Member Author

Choose a reason for hiding this comment

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

Tested these methods with various Accept-Language header locally and it was working. Not sure why?

@@ -128,6 +130,8 @@ func (l *Login) handleLoginForm(w http.ResponseWriter, req *http.Request) {
return
}

form.Locale = getLocale(getPrefferedLang(req.Header.Get("Accept-Language")))
Copy link
Contributor

Choose a reason for hiding this comment

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

What if I want to specify the language myself, manually? That's actually very often the case for myself, I default my system to English language, but prefer websites on the Czech web to be in Czech, which oftentimes I have to do manually on Czech pages since the autodetection is wrong.

I would expect some kind of this + a language button choice of which is stored in a cookie.

Copy link
Member Author

Choose a reason for hiding this comment

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

What if I want to specify the language myself, manually

if we have locale for that lang it will be used, if not we default to English

I would expect some kind of this + a language button choice of which is stored in a cookie.

This story only contains reading the lang preferences from the header and parsing the go template with appropriate locale.

Copy link
Member

Choose a reason for hiding this comment

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

@stlaz We have this for console itself. The problem is that it's stored as a user preference, which is tied to a specific user. Here you haven't logged in yet, so we can't load your user preferences.

We could also store the last selected language in localStorage and pass it as a query parameter to the login page, however. Then the query parameter would override Accept-Language if present. @jhadvig Do you might also checking a lng query parameter (to match what we support in console) first, then falling back to Accept-Language?

Note that "preferred" is misspelled here :)

@jhadvig
Copy link
Member Author

jhadvig commented Apr 7, 2021

@stlaz thanks for review.
@spadgett shall we incorporate an enhancement into the story ?

@spadgett
Copy link
Member

spadgett commented Apr 7, 2021

@stlaz We can update our existing i18n enhancement to cover the login page:

https://github.com/openshift/enhancements/blob/master/enhancements/console/internationalization.md

@spadgett
Copy link
Member

spadgett commented Apr 7, 2021

@jhadvig What are the messages we need? We can reach out to the globalization team to try to get them right away. We might already have "Username" and "Password" from other parts of the UI.

@jhadvig
Copy link
Member Author

jhadvig commented Apr 7, 2021

@spadgett its just a handful of strings, check

var locale_en = map[string]string{
"LogInToYourAccount": "Log in to your account",
"Username": "Username",
"Password": "Password",
"LogIn": "Log in",
"LoginTitle": "Login",
"WelcomeTo": "Welcome to",
"LogInWith": "Log in with",
"Error": "Error",
}

We might already have "Username" and "Password" from other parts of the UI.

I would rather have all of the string translated before enabling locale.

@spadgett
Copy link
Member

spadgett commented Apr 7, 2021

@jhadvig I think we'll need to use i18next-parser comments in the console code base so that these messages are added automatically for translation.

// t('Log in to your account')
// t('Username')
// ... etc ...

Then our existing process for sending messages for translation will work. It would be a manual update to this repo when something changes, but I think that would be rare and something the console team can take on if @stlaz and @mtrmac agree. We should add this detail to our existing i18n enhancement.

We have "Username", "Password", and "Error" translated already, but not the other strings.

@mtrmac
Copy link

mtrmac commented Apr 7, 2021

FWIW I’m just a curious observer. I just wanted to make sure that a viable process of contributing translations actually exists before settling on this mechanism.

@spadgett
Copy link
Member

spadgett commented Apr 7, 2021

cc @rebeccaalpert

</div>
</form>
</div>
</main>
<footer class="pf-c-login__footer">
<p>Welcome to OKD.</p>
<p>{{ .Locale.WelcomeTo }} OKD</p>
Copy link
Member

Choose a reason for hiding this comment

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

I think we lost the product name here.

Copy link
Member Author

Choose a reason for hiding this comment

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

did we ? I still see the OKD there, we just pulled it out of the double curly brackets.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I missed that. Really you're not supposed to concat strings, instead making them a parameter in the message so the order of the words can change. That might be tricky here.

Choose a reason for hiding this comment

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

OKD should be in the double curly brackets.

Copy link
Member

Choose a reason for hiding this comment

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

@rebeccaalpert That doesn't work here since it's a Go template and not using i18next :/

Copy link

@rebeccaalpert rebeccaalpert Apr 7, 2021

Choose a reason for hiding this comment

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

Bleh. Aiko did raise this as an issue re: ordering.

I let them all know the context, but it's better if we can give them good inputs from the beginning.

Copy link
Member

@sg00dwin sg00dwin Apr 8, 2021

Choose a reason for hiding this comment

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

Sorry, I missed that. Really you're not supposed to concat strings, instead making them a parameter in the message so the order of the words can change. That might be tricky here.

@jhadvig how will this need to be structured to handle translation changes to word order? eg. if locale_jp becomes OKD {{ .Locale.WelcomeTo }}

@rebeccaalpert
Copy link

rebeccaalpert commented Apr 7, 2021

@spadgett - @sgoodwin had sent these strings over to me and I'd manually created a PO file and sent it over to Terry's team on March 30 (you were CCed on that one). They assigned it out and said they'd give it back to us with the other strings from the last sprint.

If we can get the parser to pick these up, that would be great!

<ul>
{{ range $provider := .Providers }}
<li class="idp">
<a href="{{$provider.URL}}" class="pf-c-button pf-m-secondary pf-m-block" title="Log in with {{$provider.Name}}">{{$provider.Name}}</a>
<a href="{{$provider.URL}}" class="pf-c-button pf-m-secondary pf-m-block" title="{{ .Locale.LogInWith }} {{$provider.Name}}">{{$provider.Name}}</a>

Choose a reason for hiding this comment

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

The translators generally need full sentences. I think this may cause issues because it's broken up.

Copy link
Member Author

Choose a reason for hiding this comment

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

@rebeccaalpert so we will need to have atranslations for the Log In With string together with all the product variations ?

Choose a reason for hiding this comment

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

I think that's safer, yeah. Like Sam mentioned above sometimes the ordering of the sentence can change depending on the language.

Copy link
Member

Choose a reason for hiding this comment

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

The platform name is now included with the key string for the translators
"Welcome to {{platformTitle}}": "Welcome to {{platformTitle}}",
openshift/console#8587 (comment)

Choose a reason for hiding this comment

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

Thank you!

Copy link
Member

Choose a reason for hiding this comment

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

@sg00dwin @rebeccaalpert I'm not sure we can make that work in this context. The OAuth server won't know which platform name to use. Branding is done by replacing the entire login page template.

We might have to use string concatenation for now since we don't have the i18next library here.

sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request May 5, 2021
@jhadvig
Copy link
Member Author

jhadvig commented May 5, 2021

@stlaz comments addressed.

sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request May 5, 2021
sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request May 5, 2021
sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request May 5, 2021
@jhadvig jhadvig force-pushed the CONSOLE-2535 branch 2 times, most recently from 5e13b1e to 903a9fd Compare May 5, 2021 15:35
sg00dwin added a commit to sg00dwin/oauth-templates that referenced this pull request May 5, 2021
Switch title separator from dash to dot for consistency with rest of console
relates to openshift/oauth-server#71
update README testing instructions.
import "golang.org/x/text/language"

func GetLocale(acceptLangHeader string) map[string]string {
langBase := getPreferredLang(acceptLangHeader)
Copy link
Contributor

Choose a reason for hiding this comment

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

this should also work and be slightly faster, right?

type Localization map[string]string

var supportedLocalizations = map[string]Localization
    language.English.String(): locale_en,
    language.Chinese.String(): locale_zh,
   ...
}

func GetLocale(acceotedLangHeader string) Localization {
    locale, ok := supportedLocalizations[getPreferredLang(acceptLangHeader)]
    if !ok {
        return locale_en
    }
    return locale
}

Can we index by Tags?

Copy link
Member Author

Choose a reason for hiding this comment

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

we can 👍

matcher := language.NewMatcher(supportedLangs)
userPrefs, _, err := language.ParseAcceptLanguage(acceptLangHeader)
if err != nil {
// if error occurs, fallback to English
Copy link
Contributor

Choose a reason for hiding this comment

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

dump this error to debug logs

return language.English.String()
}
tag, _, _ := matcher.Match(userPrefs...)
base, _ := tag.Base()
Copy link
Contributor

Choose a reason for hiding this comment

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

no language variations?

@jhadvig
Copy link
Member Author

jhadvig commented May 6, 2021

@stlaz thanks for review, comments addressed 👍

matcher := language.NewMatcher(supportedLangs)
userPrefs, _, err := language.ParseAcceptLanguage(acceptLangHeader)
if err != nil {
klog.Warningf("Error parsing 'Accept-Language' header, falling back to English language: %v", err)
Copy link
Contributor

Choose a reason for hiding this comment

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

debug log please (lower verbosity)

@stlaz
Copy link
Contributor

stlaz commented May 6, 2021

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label May 6, 2021
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jhadvig, stlaz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 6, 2021
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@jhadvig jhadvig changed the title CONSOLE-2535: Internationalize login page Bug 1958080: CONSOLE-2535: Internationalize login page May 7, 2021
@openshift-ci openshift-ci bot added the bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. label May 7, 2021
@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 7, 2021

@jhadvig: This pull request references Bugzilla bug 1958080, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.8.0) matches configured target release for branch (4.8.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

Requesting review from QA contact:
/cc @yapei

In response to this:

Bug 1958080: CONSOLE-2535: Internationalize login page

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci bot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label May 7, 2021
@openshift-ci openshift-ci bot requested a review from yapei May 7, 2021 06:57
@openshift-merge-robot openshift-merge-robot merged commit 3da20bd into openshift:master May 7, 2021
@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 7, 2021

@jhadvig: All pull requests linked via external trackers have merged:

Bugzilla bug 1958080 has been moved to the MODIFIED state.

In response to this:

Bug 1958080: CONSOLE-2535: Internationalize login page

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants