[FOLIO-1422] Change language setting causes wrong UI labels Created: 17/Aug/18 Updated: 12/Nov/18 Resolved: 30/Aug/18 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Bug | Priority: | P3 |
| Reporter: | Hongwei Ji | Assignee: | md331 (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | i18n, regression, sprint45 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||||||||||
| Description |
|
1, go to stable or testing site |
| Comments |
| Comment by Cate Boerema (Inactive) [ 21/Aug/18 ] |
|
I don't think we actually have many translation files, but there should be for Hungarian and I know we had German translations for Users. I'm not seeing any of those in snapshot-stable. Can you please take a look, István Bender? |
| Comment by Julian Ladisch [ 21/Aug/18 ] |
|
I've reduced the scope of this ticket. We already have
|
| Comment by István Bender [ 21/Aug/18 ] |
|
Currently I cannot access the stable testing site. Anyway lokalize was set up by Peter Murray. Őerhaps he can help as well. |
| Comment by Peter Murray [ 21/Aug/18 ] |
|
Recalling the last conversation I had with John Coburn as I was working on
|
| Comment by Peter Murray [ 23/Aug/18 ] |
|
I'm quite puzzled by the results of pushing the language files into GitHub. For all languages but English, switching the language displays the keys not the strings, even though every key always has a value now (even if it is the base language, English). For instance, there is a value for `meta.title` for German in ui-users (https://github.com/folio-org/ui-users/blob/master/translations/ui-users/de.json#L513) but if I switch the language on folio-testing to German I get the key. Asking on Slack whether I'm missing something. |
| Comment by Zak Burke [ 24/Aug/18 ] |
|
John Malconian, Matthew Jones, can we add the --languages parameter to the build process for folio-testing and folio-snapshot to include the list of currently supported languages, en-US, en-GB, da-DK, de-DE, hu-HU? |
| Comment by Peter Murray [ 24/Aug/18 ] |
|
The `da`, `de`, and `hu` languages do not have country modifiers in our language files; there is just the bare language code. Also add `es_ES`. |
| Comment by Peter Murray [ 24/Aug/18 ] |
|
Here is the full list of language and language-country pairs that we have some translation strings for at this point:
|
| Comment by John Malconian [ 24/Aug/18 ] |
|
I updated folio-testing platform to use stripes-cli to build the webpack which supports the '--languages' option at build time. However, I've specified builds with both '--languages da,de,en,es_ES,fr,hu,it_IT,pt_BR' as well as '--languages en-US, en-GB, da-DK, de-DE, hu-HU' without success. In both cases, I get a build that contains no text. If someone knows the secret sauce on how this needs to be specified, let me know. |
| Comment by John Malconian [ 27/Aug/18 ] |
|
Matthew Jones Can you drop some hints here on how to utilize the stripes-cli '--languages' option? |
| Comment by Matthew Jones [ 27/Aug/18 ] |
|
John Malconian, array options in the CLI are space-separated. The --languages options would look like this: stripes build stripes.config.js outputdir --languages da de en This has the same effect as specifying languages in the stripes tenant config:
okapi: {
url: 'http://localhost:9130',
tenant: 'diku',
},
config: {
logCategories: 'core,path,action,xhr',
languages: ['da', 'de', 'en'],
},
However, we shouldn't need to apply the languages option to include all languages. The languages option acts as a filter. When languages are omitted entirely, no filter is applied and all available language files are included. If this is not happening, then there may be a bug. |
| Comment by Matthew Jones [ 27/Aug/18 ] |
|
Looking at http://folio-testing.aws.indexdata.com/ right now, I do see the network traffic loading additional translation files from the build after selecting a different language and saving. For example: http://folio-testing.aws.indexdata.com/translations/de-1535378616203.json Therefore, we shouldn't need to tinker with --languages option. This may be a rendering issue. |
| Comment by Matthew Jones [ 27/Aug/18 ] |
|
Looking into this further, I see the translation file being requested and the resulting store.dispatch invoked with the correct translation strings, as fetched from the server. In stripes-core's loginServices.js:
export function loadTranslations(store, locale) {
const parentLocale = locale.split('-')[0];
return import(`react-intl/locale-data/${parentLocale}`)
.then(intlData => addLocaleData(intlData))
.then(() => fetch(translations[parentLocale]))
.then((response) => {
if (response.ok) {
response.json().then((stripesTranslations) => {
store.dispatch(setTranslations(stripesTranslations)); // <-- looks good
store.dispatch(setLocale(locale));
});
}
});
}
I also see the okapiReducer called with the correct translations strings:
case 'SET_TRANSLATIONS':
return Object.assign({}, state, { translations: action.translations }); // <-- looks good
After this, production builds begin reporting React Intl errors like this in the console: [React Intl] Missing message: "stripes-core.loggedInAs" for locale: "en" The interesting thing is, no matter which language I select, React Intl will report missing messages for locale: "en". I am not familiar with how the messages are handled in the UI beyond this point, but it seems suspect to me that React Intl would still be reporting on, and presumably looking for, a local of "en" when another has been selected. In summary, the translations are built, fetched, and available in the UI. This appears to be a problem with the render. Can anyone with familiarity in this area shed some light, Mike Taylor or md331? |
| Comment by Matthew Jones [ 27/Aug/18 ] |
|
A couple more observations I forgot to mention above: When looking at <IntlProvider> with the React dev tools, I see the correct messages for the selected language. <RootWithIntl>'s render is called 3 times after switching languages. When switching to something other than "en", the third call has an empty this.context.intl.messages object.
render() {
const intl = this.context.intl; // <-- does not always have .messages populated
|
| Comment by Zak Burke [ 28/Aug/18 ] |
|
Apologies if I threw you under the bus, here, Matthew Jones! The timing of this issue in concert with the changes under
|
| Comment by md331 (Inactive) [ 29/Aug/18 ] |
|
I think I figured this out. PR is here along with my spelunking notes but I would love someone to double-check my assumptions. |
| Comment by Peter Murray [ 30/Aug/18 ] |
|
With the PR merged, I think this is okay. I quickly tried switching the locale to Germany – I got the German labels where such translations were defined, English labels where Lokalise didn't have a German translation, and translation keys where German language files hadn't been uploaded into GitHub yet. It is fine to close this issue as far as I'm concerned. Does it look okay to everyone else? |
| Comment by Hongwei Ji [ 30/Aug/18 ] |
|
Verified on stable site with Danish, German, and Hungarian. All look good. I will mark the ticket as resolved. |