Hi.
We believe that it's meaningful to internationalize the Dashboard, which will make Tekton easier to use for non-native people.
For this reason, we proposed internationalization in Slack before.
Thank you for your response at that time.
We create this issue according to your reply.
There are two things we want to confirm.
Does the Dashboard project define the translation process? If not, We'd like to discuss it with you.
For reference, we researched several famous projects.
The Kubernetes example is helpful. For each language, they seem to have one team responsible for reviewing.
The other two have written translations, but there is no process within the community. They may not make it public.
However, it would be grateful if you extended the current https://github.com/tektoncd/dashboard/tree/master/docs/dev#i18n as they do.
We think we can add a translation by modifying the code as follows, is this correct?
src/nls/messages_ja.jsonja to locales.build in config_frontend/config.jsonnpm run nlssrc/nls/messages_ja.json filled with only keysrc/nls/messages_ja.jsonsrc/nls/messages_ja.json on src/containers/App/App.jsWe will help you with the translation into Japanese.
Thanks.
we don't have a formal translation process documented for the community but can certainly improve the existing development docs to include more information about the expected format etc. Thank you for the links to those other processes, I'll review them and see what makes sense to include for the dashboard.
we already have https://github.com/tektoncd/dashboard/blob/master/src/nls/messages_ja.json partially populated with translations, mostly for the PipelineRuns and PipelineRun components. Additional translations can be added to that file by replacing the empty string values.
The translations are not exposed in the UI yet, so as you stated src/containers/App/App.js would need to be modified to load the correct file based on the browser locale. We should allow developers to view even partial translations while working on the dashboard / translations, and once a given locale is complete (or at an acceptable level) we would add it to locales.supported in config.json so it would be loaded for a production build too.
Thank you very much for your kind advice, @AlanGreene !!
Our team are thinking of implementing this feature.
Hope we could issue a PR within a few weeks.
Should you have any requests for us (for example: discuss before starting implementation), please suggest me.
Thanks a lot.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Some progress has been made here, see for example recent updates to the Japanese translations and the contribution of a style guide https://github.com/tektoncd/dashboard/pull/1879 with specific guidance for formatting, non-translatable content, etc. in the Japanese string bundle.
/lifecycle frozen
As being commented in #1808 , Dynamic import should be implemented to i18n, but we are struggling with this implementation.
Hopefully we could let you know the problems concerning this within a few days.
I was trying implementing Dynamic Import following an advice from community and studying React, but something seemed to be wrong.
If you had any advice or support, I would be very grateful.
In the advice's case, what imported dynamically is a component, not a json file. In my understanding, only in importing a component dynamically we can use "React.lazy".
In this case, on the other hand, what imported dynamically is a json file (e.g. messages_ja.json).
I have implemented mainly as the following ways, but none of them worked well:
Failed to load module script: The server responded with a non-JavaScript MIME type of "application/json". Strict MIME type checking is enforced for module scripts per HTML spec.Our team would keep studying React!!
Thank you.
Taking a look at this now...
This works reasonably well: https://github.com/AlanGreene/dashboard/commit/abaac5772f11301a2a0ccb78cd40d6db07bdb9c0
The core piece is:
const { default: messages } = await import(
/* webpackChunkName: "[request]" */ `../../nls/messages_${this.props.lang}.json`
);
The webpackChunkName magic comment ensures that webpack names the output files in the dist folder like messages_ja-json.[hash].js instead of 338.[hash].js (using an incrementing id is the default for unnamed chunks).
There's some work remaining, such as checking locales.supported as mentioned in https://github.com/tektoncd/dashboard/issues/1727#issuecomment-698859714
We should only load a message bundle for a supported locale in a production build, if the browser locale is not supported we should fall back to the default locale.
Let me know if you have any questions or need any further help with this 馃樃
Thank you very much for your helpful support @AlanGreene !!
Our team will be trying checking locales.supported .
Thank you again!
Thanks to @kobaji @rudeigerc @yamaken1343 @kkosaka and everyone else who has contributed translations or code changes to support this 馃帀
Thanks to helpful supports by @AlanGreene our team could commit.
Thank you very much.
Most helpful comment
Thanks to @kobaji @rudeigerc @yamaken1343 @kkosaka and everyone else who has contributed translations or code changes to support this 馃帀