-
Notifications
You must be signed in to change notification settings - Fork 33
feat: Relates to #402. Internationalisation. Base Support #452
Conversation
I've pushed commits so we can toggle between the English and German languages. However I Could someone fluent in German please review packages/fether-react/src/i18n/locales/de.json to check that the German translation is correct (since I've just used Google Translate)? Where in the UI will we allow users to toggle between different supported languages?
How will we approach translating the legal Terms of Use in /Users/scon/code/src/paritytech/fether/packages/fether-react/src/Onboarding/termsAndConditions.md into different supported languages? |
Although it's a feature that definitely brings a lot of value, I think it's a little early to invest too much time on it. Bounties or challenges (win a parity t-shirt and goodies for each language added) can help us bring a lot of languages. But we need mainnet and more adoption for that. The T&Cs is a tricky part, we might need to keep them in english for now. |
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.
Impressive!
We forgot small things like transaction speed High
and Low
in /fether-react/src/Send/TxForm/TxForm.js
The tooltip when hovering the "amount" field on the TxForm
is still in english (it reads "Please fill out this field"). This comes from the chrome engine, we should disable it by adding novalidate="novalidate"
to the <form>
.
I've tested a lot but probably not everything yet.
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.
Nice! Works well, I have some small comments, mainly questions, as I'm not super familiar with this lib.
.use(Backend) | ||
.init({ | ||
debug: true, | ||
defaultNS: 'ns1', |
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 suppose ns1
stands for namespace 1. Should we rename it to fether-electron
here and fether-react
in the react folder? Or something else shorter, but more relevant
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, agreed
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've renamed it to the package name from package.json. And if a fether-react component uses a child component from fether-ui then it uses the fether-react namespace
}); | ||
|
||
i18next.on('initialized', options => { | ||
pino.info('i18n backend: Detected initialisation of i18n'); |
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 some of these could be pino.debug
.
@@ -1,3 +1,8 @@ | |||
// Copyright 2015-2018 Parity Technologies (UK) Ltd. |
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.
2019 (multiple instances)
// https://react.i18next.com/getting-started | ||
import i18next from 'i18next'; | ||
// // https://github.com/i18next/i18next-browser-languageDetector | ||
import LanguageDetector from 'i18next-browser-languagedetector'; |
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.
Does this work in Electron?
Also, why do we need it? Imo: language should be set/detected by electron, then electron emits the IPC message set-language
, and fether-react just follows what electron says.
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, you're correct. I just removed it and it works, so we don't need it
}, | ||
saveMissing: true | ||
}) | ||
.then(() => console.log('i18n frontend: success')) |
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.
Use debug, no console.logs.
packages/fether-react/src/App/App.js
Outdated
.getCurrentWindow() | ||
.webContents.addListener('set-language', newLanguage => { | ||
i18n.changeLanguage(newLanguage); | ||
store.set(LANG_LS_KEY, newLanguage); |
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.
If I understood correctly, this setting is already saved in electron-settings
. Isn't saving it in localStorage redundant?
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 I was deciding where to save the user's language setting I found I only had access to electron-settings in the fether-electron package, but not in fether-react (and I don't think we'd want the front-end to have access to the file system anyway). I need to store the language in localStorage too since I'm using i18n in the front-end for the Fether contents, and when it initialises it sets the language to lng
in /Users/scon/code/src/paritytech/fether/packages/fether-electron/src/main/app/menu/i18n/index.js based on the language last saved in localStorage or English as a fallback, and when the App.js component finishes mounting it checks if the language saved in localStorage differs from the currently set i18n language, and if so it retrieves the latest localStorage language value and sets that to the i18n language (see /Users/scon/code/src/paritytech/fether/packages/fether-react/src/App/App.js).
fether-electron has the Fether menu language config.
- i18n config initialises to the language stored in electron-settings under key
fether-language
, or uses fallback default language of English (see fether-electron/src/main/app/menu/i18n/index.js) - When it's setting up the Fether menu it determines which language checkbox to tick based on the value of the key
fether-language
stored in electron-settings. See /Users/scon/code/src/paritytech/fether/packages/fether-electron/src/main/app/menu/template/index.js - If the user clicks one of the languages in the Fether menu, then it triggers the click handler, which changes the fether-electron i18n language, sets the
fether-language
key in electron-settings to the language that was clicked, updates the Fether menu, and emitsset-language', which the fether-react event listener handles by changing the fether-react i18n language, sets the
fether-language` key in localStorage to the language that was clicked, and reloads the Fether window. See /Users/scon/code/src/paritytech/fether/packages/fether-react/src/App/App.js
fether-react has the i18n Fether contents language config
- i18n config initialises to the language stored in localStorage under key
fether-language
, or uses fallback default language of English (see /Users/scon/code/src/paritytech/fether/packages/fether-react/src/i18n/index.js)
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.
i18n config initialises to the language stored in localStorage
My idea is:
- fether-electron stores user's language in
electron-settings
- we agree on that - On startup (i.e.
componendDidMount
inside App.js), react reads from IPC from electron (i.e. usingelectron.remote
) and sets the language accordingly - Everytime react receives a
set-language
IPC message, it changes the language accordingly
There's really no need for localStorage
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.
But the problem is that after the user changes the language in the UI, first the click ()
handler for the language they chose changes the language in fether-electron's i18n config and updates the Fether menu, which successfully changes the language shown in the Fether menu (but not the Fether window contents), but then it emits the 'set-language'
event which triggers the addListener('set-language'
block in componendDidMount
of App.js where it changes the i18n language in the front-end to match the new language stored in electron-settings
. But then in order for the Fether window contents to change to the new language that was emitted, we need to reload the Fether window, which is why we end the block with electron.remote.getCurrentWindow().webContents.reload();
, but when it reloads, it also reloads the front-end i18n configuration back to its defaults.
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've created a separate branch where I've added two additional commits, one that merges the German language branch into this branch (so you can see that it works switching between languages, noting that I've actually added the German language support as a separate PR), and a second commit where i've tried get your idea to work unsuccessfully https://github.com/paritytech/fether/compare/luke-402-i18n-temp?expand=1
Thanks, yes I found that I had to add |
@Tbaut @amaurymartiny I've pushed commits that I believe address your review comments |
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.
👍 LGTM
@amaurymartiny @Tbaut i've updated this PR ready for review incorporating all the latest changes in master and resolving merge conflicts
|
i've created a Fether FAQ PR https://github.com/paritytech/wiki/pull/327 that explains:
|
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.
Looks good!
@ltfschoen I looked at your commit, but I'm still convinced we don't need to store language in localStorage. Anyways, this PR is working, my proposal is just optimization after-all, so let's merge it.
…)" This reverts commit 649d6bf.
Update to latest React.js to support react-i18n library
Added support for multiple locales. Able to change between different languages (separate PRs shall provide other languages). Other languages may be added by following the instructions in the Readme
Translate Fether menus and Fether window contents
Integrate into menu (i.e. preferences/settings) or try to automatically detect the language
Check that it works consistently across Windows and Linux, as well as macOS
Move some "Internationalisation" sections from README.md into the Fether FAQ of the Parity Wiki. See 88c9b18#diff-04c6e90faac2675aa89e2176d2eec7d8R187
Convert all text in fether-electron i18n config file into i18n. See 88c9b18#diff-e71da345e8fcc8df02de6ee26e679513R43 Not required as discussed with Tbaut
Convert all text in fether-react i18n config file into i18n. See 88c9b18#diff-473a1d2ae1b77ea2a159e91cf293fe6cR50 Not required as discussed with Tbaut
Convert all text in scripts/fetch-latest-parity.js into i18n. Not required as discussed with Tbaut
Notes: