-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add i18n library to Linkerd dashboard #4803
Conversation
return ( | ||
<Card className={classes.card} elevation={3}> | ||
<CardContent> | ||
<Typography> | ||
{content} | ||
<Trans>No data to display</Trans> |
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 is an example of translating a static text string.
Also, we were never passing in a prop content
to this component, so we could remove the propTypes checks.
|
||
return ( | ||
<Typography variant="body2"> | ||
<Trans> |
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 is an example of translating a block of text containing a dynamic text value.
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.
Thanks @scottcarol , the explained workflow feels pretty smooth 💃 (you only missed mentioning under the "adding locale section" adding the new locale into the catalogs
const).
One very specific edge case I tested was "generic locale fallback" support, that helps overriding specific translations that differ across countries using the same language (that I also mentioned in the previous PR). So I added one catalog for es
and another for es-CO
; by the way this is the right format that took me a bit to figure:
const catalogs = { en: catalogEn, es: catalogEs, "es-CO": catalogEsCo, fr: catalogFr };
If I browsed the site with a "es-CO" locale it will rightly show the translations. If a message isn't translated it will fallback to the English word, but I was hoping it would fallback to the generic es
translation. Maybe that's just a lingui
limitation? Anyways, not a deal breaker if so.
web/app/js/index.js
Outdated
@@ -72,9 +75,13 @@ class App extends React.Component { | |||
} | |||
|
|||
render() { | |||
const catalogs = { en: catalogEn, es: catalogEs }; |
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 mean every translation will get loaded regardless of the current user language? If so, probably not a big deal, but would be better if they could be loaded dynamically...
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.
Good point, I updated it so that we are only passing the necessary catalog into I18nProvider
.
I tried taking it one step further and dynamically loading the specific catalog we needed into index.js
:
const selectedCatalog = require(`./locales/${selectedLocale}/messages.js`);
but I hit the no-dynamic-require es-lint rule, which seems to be best practices, so I am continuing to load all of the possible catalogs into this file.
web/app/package.json
Outdated
"add-locale": "lingui add-locale", | ||
"extract": "lingui extract", | ||
"compile": "lingui compile" |
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.
These aliases can be less expressive than the original command. yarn compile
in particular sounds like it would do more than compile locales 😉
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, that's a good point. To be more explicit, I updated the commands so they include lingui
.
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.
In that case the scripts
section is no longer necessary, is it? Or are you leaving that there just to document the available commands?
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.
You're totally right, it's not needed now. Just removed, and the BUILD.md
should be the file with the documentation of commands. I can add documentation in the follow-up PR I will make after this.
@alpeb Thanks for taking a look! Based on your feedback around generic locale fallback support, I took a look in the If my browser locales are If this updated branch makes sense to you, I'll pull out the logic into its own |
Nice, this fixes the case when say the browser uses Do you know if there's a chance to have this fallback mechanism operate at the single phrase level? |
Good question @alpeb:
When we run |
@alpeb I can't immediately find best practices on individual default fallback values, but if it's ok with you, we could merge this PR, in a follow-up PR add translations for |
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.
@alpeb I can't immediately find best practices on individual default fallback values, but if it's ok with you, we could merge this PR, in a follow-up PR add translations for es and en, and then decide on our process for adding locale-SPECIFIC formats.
Yeah definitely! I was you wondering about that since I remembering doing that for some project a thousand years ago, but this is shippable as is 👍 🥇
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, we probably want to use keys instead of the strings themselves as keys but that's an eventual improvement.
Part of #3651
This PR adds the LinguiJS project to the Linkerd dashboard for i18n and translation. This is an open source project that is well documented and updated, with an active community. After evaluating several libraries this seemed like a lightweight option with easy CLI tools, making it easy for other contributors to learn and use.
This PR ONLY changes 2 React components. The purpose is for reviewers to evaluate the use of the library, adding a language, editing translations, compiling, etc. After this approach is validated a second PR will go up which adds translations for all of the remaining components.
How to test this PR
Viewing the dashboard
Check out this branch and run
bin/web dev
orbin/web run
.With your browser language set to
en
open http://localhost:7777/namespaces/linkerd/replicationcontrollersIf you have the standard Linkerd setup you should see:
Change your browser language to
es
. You should see:Adding a translation
Namespace.jsx
in your code editor.Trans
and wrapping text in it.web/app
runyarn extract
locales/es/messages.json
andlocales/en/messages.json
and fill in the blanks.yarn extract
again. It should say you have 0 missing translations.yarn compile
.en
browser and anes
browser. You should see the translations you put in. If your browser is set to a different language, only the English key will show.Adding a locale
web/app
runyarn add-locale fr
thenyarn extract
locales/fr/messages.json
and add sample valuesimport catalogFr from './locales/fr/messages.js’;
toindex.js
yarn compile
fr
Signed-off-by: Carol Scott carol@buoyant.io