-
Notifications
You must be signed in to change notification settings - Fork 48
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
Conversation
@jhadvig |
5efca2a
to
6c96a14
Compare
@stlaz we are ready for review. PTAL |
/retest |
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.
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.
pkg/server/login/locales.go
Outdated
} | ||
|
||
var locale_en = map[string]string{ | ||
"": "", |
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.
what's the empty string key for?
pkg/server/login/locales.go
Outdated
switch langBase { | ||
case language.English.String(): | ||
return locale_en | ||
// Uncomment once given locale is available |
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.
When is that going to be?
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.
Thats up to translations team that is providing those.
@sg00dwin any estimations ?
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.
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?
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.
@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.
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.
Thats up to translations team that is providing those.
@sg00dwin any estimations ?
The translation team doesn't provide estimated turn around times. Still waiting.
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.
Translated strings are now included for each language.
pkg/server/login/locales.go
Outdated
|
||
func getLocale(langBase string) map[string]string { | ||
switch langBase { | ||
case language.English.String(): |
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 do I know this works?
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.
Tested these methods with various Accept-Language header locally and it was working. Not sure why?
pkg/server/login/login.go
Outdated
@@ -128,6 +130,8 @@ func (l *Login) handleLoginForm(w http.ResponseWriter, req *http.Request) { | |||
return | |||
} | |||
|
|||
form.Locale = getLocale(getPrefferedLang(req.Header.Get("Accept-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.
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.
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.
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.
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.
@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 :)
@stlaz We can update our existing i18n enhancement to cover the login page: |
@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. |
@spadgett its just a handful of strings, check oauth-server/pkg/server/login/locales.go Lines 41 to 50 in 6c96a14
I would rather have all of the string translated before enabling locale. |
@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. |
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. |
</div> | ||
</form> | ||
</div> | ||
</main> | ||
<footer class="pf-c-login__footer"> | ||
<p>Welcome to OKD.</p> | ||
<p>{{ .Locale.WelcomeTo }} OKD</p> |
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 we lost the product name 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.
did we ? I still see the OKD
there, we just pulled it out of the double curly brackets.
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.
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.
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.
OKD should be in the double curly brackets.
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.
@rebeccaalpert That doesn't work here since it's a Go template and not using i18next :/
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.
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.
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.
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 }}
@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> |
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 translators generally need full sentences. I think this may cause issues because it's broken up.
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.
@rebeccaalpert so we will need to have atranslations for the Log In With
string together with all the product variations ?
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's safer, yeah. Like Sam mentioned above sometimes the ordering of the sentence can change depending on the 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.
The platform name is now included with the key string for the translators
"Welcome to {{platformTitle}}": "Welcome to {{platformTitle}}",
openshift/console#8587 (comment)
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.
Thank you!
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.
@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.
relates to openshift/oauth-server#71 update README testing instructions.
@stlaz comments addressed. |
relates to openshift/oauth-server#71 update README testing instructions.
relates to openshift/oauth-server#71 update README testing instructions.
relates to openshift/oauth-server#71 update README testing instructions.
5e13b1e
to
903a9fd
Compare
Switch title separator from dash to dot for consistency with rest of console relates to openshift/oauth-server#71 update README testing instructions.
pkg/server/locales/locales.go
Outdated
import "golang.org/x/text/language" | ||
|
||
func GetLocale(acceptLangHeader string) map[string]string { | ||
langBase := getPreferredLang(acceptLangHeader) |
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 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?
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 can 👍
pkg/server/locales/locales.go
Outdated
matcher := language.NewMatcher(supportedLangs) | ||
userPrefs, _, err := language.ParseAcceptLanguage(acceptLangHeader) | ||
if err != nil { | ||
// if error occurs, fallback to English |
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.
dump this error to debug logs
return language.English.String() | ||
} | ||
tag, _, _ := matcher.Match(userPrefs...) | ||
base, _ := tag.Base() |
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.
no language variations?
@stlaz thanks for review, comments addressed 👍 |
pkg/server/locales/locales.go
Outdated
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) |
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.
debug log please (lower verbosity)
/lgtm |
[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 |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@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
Requesting review from QA contact: In response to this:
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. |
@jhadvig: All pull requests linked via external trackers have merged: Bugzilla bug 1958080 has been moved to the MODIFIED state. In response to this:
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. |
@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