internationalization for the web UI
Hello,
Here is a WIP patch that aims to add support for translating Zuul's web UI: https://review.opendev.org/737290 . After trying unsuccessfully to work with react-i18next [0] as it seems to be the most popular i18n library for react, I've had more success with react-redux-i18n [1] (i18next didn't seem to play nice with some redux things). This choice of library, however, is not perfect: Pros: - relatively painless integration with zuul-web's existing code Cons: - no new commit on the library in 2 years - All the translations are loaded in the store as the web app is initially loaded in the browser. There aren't many text strings to localize, but as more languages get supported, this might mean a lot of potentially useless data will have to be downloaded in the browser. (OTOH react-i18next can load the right locale when needed)
If there any better choices of library and/or implementation, please let me know through reviews. Until then I won't work more on this, as listing the translatable strings is a bit of a chore and I'd rather make sure we're all on agreement about how to do Zuul i18n. Once this is cleared, will come the fun times of nitpicking exact translations of Zuul terms in the language of your choice. :)
Cheers,
[0]: https://react.i18next.com/ [1]: https://github.com/artisavotins/react-redux-i18n
Matthieu Huin mhuin@redhat.com writes:
Hello,
Here is a WIP patch that aims to add support for translating Zuul's web UI: https://review.opendev.org/737290 . After trying unsuccessfully to work with react-i18next [0] as it seems to be the most popular i18n library for react, I've had more success with react-redux-i18n [1] (i18next didn't seem to play nice with some redux things). This choice of library, however, is not perfect: Pros:
- relatively painless integration with zuul-web's existing code
Cons:
- no new commit on the library in 2 years
- All the translations are loaded in the store as the web app is initially
loaded in the browser. There aren't many text strings to localize, but as more languages get supported, this might mean a lot of potentially useless data will have to be downloaded in the browser. (OTOH react-i18next can load the right locale when needed)
If there any better choices of library and/or implementation, please let me know through reviews. Until then I won't work more on this, as listing the translatable strings is a bit of a chore and I'd rather make sure we're all on agreement about how to do Zuul i18n. Once this is cleared, will come the fun times of nitpicking exact translations of Zuul terms in the language of your choice. :)
Cheers,
I don't have a suggestion, but just wanted to say thanks for looking into this, and I hope we identify a good solution. :)
-Jim
We've used the OpenStack i18n team in the past, which relies on Zanata [1]. I don't think that's the best solution here since Zanata is being deprecated. But it's worth reaching out to the i18n team to see if they're willing to provide some details about what they're looking for next.
That said, agreed a React plugin is probably the best way to go. I haven't used it yet, but since Zuul just moved to Gatsby, another one we could look at is https://www.npmjs.com/package/gatsby-plugin-i18n
Curious to hear what your experience is as we run a number of Gatsby sites for the OSF. If there is any assitance we can provide, please don't hesitate :)
Cheers, Jimmy
[1] e.g. https://translate.openstack.org/iteration/view/2019-openstack-foundation-ann...
Matthieu Huin wrote on 6/22/20 10:40 AM:
Hello,
Here is a WIP patch that aims to add support for translating Zuul's web UI: https://review.opendev.org/737290 . After trying unsuccessfully to work with react-i18next [0] as it seems to be the most popular i18n library for react, I've had more success with react-redux-i18n [1] (i18next didn't seem to play nice with some redux things). This choice of library, however, is not perfect: Pros:
- relatively painless integration with zuul-web's existing code
Cons:
- no new commit on the library in 2 years
- All the translations are loaded in the store as the web app is
initially loaded in the browser. There aren't many text strings to localize, but as more languages get supported, this might mean a lot of potentially useless data will have to be downloaded in the browser. (OTOH react-i18next can load the right locale when needed)
If there any better choices of library and/or implementation, please let me know through reviews. Until then I won't work more on this, as listing the translatable strings is a bit of a chore and I'd rather make sure we're all on agreement about how to do Zuul i18n. Once this is cleared, will come the fun times of nitpicking exact translations of Zuul terms in the language of your choice. :)
Cheers,
[1]: https://github.com/artisavotins/react-redux-i18n
Matthieu Huin
Senior Software Developer
Red Hat https://www.redhat.com
Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
On 2020-06-22 13:25:22 -0500 (-0500), Jimmy McArthur wrote:
We've used the OpenStack i18n team in the past, which relies on Zanata [1]. I don't think that's the best solution here since Zanata is being deprecated. But it's worth reaching out to the i18n team to see if they're willing to provide some details about what they're looking for next.
Note that Zanata is a translation platform, what OpenStack's actually been using is gettext or babel to substitute localized string equivalents at runtime. Where Zanata comes into the picture there is managing and tracking what strings have been translated, and then we have Zuul jobs in OpenDev which pull those translated strings into project Git repositories (proposing them as reviews in OpenDev's Gerrit), or push updated string manifests from projects back into Zanata for future translation. Zanata also maintains a cache of translations which can be fuzzily applied; this tends to be more useful in very large project sets where similar strings are shared in many places.
So tools like Zanata are cool, and may be useful to the Zuul project if there's an especially large amount of translation work to be done, but what Matthieu's looking into is the bit which does the substitution of translated strings at runtime.
That said, agreed a React plugin is probably the best way to go. I haven't used it yet, but since Zuul just moved to Gatsby, another one we could look at is https://www.npmjs.com/package/gatsby-plugin-i18n
[...]
Zuul's project Web site is moving to Gatsby as a CMS, but this discussion is not about the project site, it's about the WebUI provided by running deployments of the Zuul software.
That said, translations of the site are a good idea too!
Ah ha! All good clarifications :) Thank you! My brain goes website first ;)
Jeremy Stanley wrote on 6/22/20 1:36 PM:
On 2020-06-22 13:25:22 -0500 (-0500), Jimmy McArthur wrote:
We've used the OpenStack i18n team in the past, which relies on Zanata [1]. I don't think that's the best solution here since Zanata is being deprecated. But it's worth reaching out to the i18n team to see if they're willing to provide some details about what they're looking for next.
Note that Zanata is a translation platform, what OpenStack's actually been using is gettext or babel to substitute localized string equivalents at runtime. Where Zanata comes into the picture there is managing and tracking what strings have been translated, and then we have Zuul jobs in OpenDev which pull those translated strings into project Git repositories (proposing them as reviews in OpenDev's Gerrit), or push updated string manifests from projects back into Zanata for future translation. Zanata also maintains a cache of translations which can be fuzzily applied; this tends to be more useful in very large project sets where similar strings are shared in many places.
So tools like Zanata are cool, and may be useful to the Zuul project if there's an especially large amount of translation work to be done, but what Matthieu's looking into is the bit which does the substitution of translated strings at runtime.
That said, agreed a React plugin is probably the best way to go. I haven't used it yet, but since Zuul just moved to Gatsby, another one we could look at is https://www.npmjs.com/package/gatsby-plugin-i18n
[...]
Zuul's project Web site is moving to Gatsby as a CMS, but this discussion is not about the project site, it's about the WebUI provided by running deployments of the Zuul software.
That said, translations of the site are a good idea too!
Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
We can take this opportunity to expand this thread to discussing options for translating Zuul's website. Actually, if anybody has experience with translating rst documentation with sphinx, I'd be interested to hear about it, because I was eyeing that as a summer vacation project. :)
On Mon, Jun 22, 2020 at 8:57 PM Jimmy McArthur jimmy@openstack.org wrote:
Ah ha! All good clarifications :) Thank you! My brain goes website first ;)
Jeremy Stanley wrote on 6/22/20 1:36 PM:
On 2020-06-22 13:25:22 -0500 (-0500), Jimmy McArthur wrote:
We've used the OpenStack i18n team in the past, which relies on Zanata [1]. I don't think that's the best solution here since Zanata is being deprecated. But it's worth reaching out to the i18n team to see if they're willing to provide some details about what they're looking for next.
Note that Zanata is a translation platform, what OpenStack's actually been using is gettext or babel to substitute localized string equivalents at runtime. Where Zanata comes into the picture there is managing and tracking what strings have been translated, and then we have Zuul jobs in OpenDev which pull those translated strings into project Git repositories (proposing them as reviews in OpenDev's Gerrit), or push updated string manifests from projects back into Zanata for future translation. Zanata also maintains a cache of translations which can be fuzzily applied; this tends to be more useful in very large project sets where similar strings are shared in many places.
So tools like Zanata are cool, and may be useful to the Zuul project if there's an especially large amount of translation work to be done, but what Matthieu's looking into is the bit which does the substitution of translated strings at runtime.
That said, agreed a React plugin is probably the best way to go. I haven't used it yet, but since Zuul just moved to Gatsby, another one we could look at ishttps://www.npmjs.com/package/gatsby-plugin-i18n
[...]
Zuul's project Web site is moving to Gatsby as a CMS, but this discussion is not about the project site, it's about the WebUI provided by running deployments of the Zuul software.
That said, translations of the site are a good idea too!
Zuul-discuss mailing listZuul-discuss@lists.zuul-ci.orghttp://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
On 22.06.20 21:05, Matthieu Huin wrote:
We can take this opportunity to expand this thread to discussing options for translating Zuul's website. Actually, if anybody has experience with translating rst documentation with sphinx, I'd be interested to hear about it, because I was eyeing that as a summer vacation project. :)
This is done today already, see the releasenotes translations for example on https://docs.openstack.org/releasenotes/nova/ .
Sphinx can use translation files to build translated docs and we use that for some documemts already. Translation happens in Zanata and then we have some infrastructure for translation, see also docs.openstack.org/i18n/
Andreas
Since there was no opposition so far to react-redux-i18n, I went on and finished the translation coverage. French speakers: vous pouvez voir ce que ça donne ici: https://882d44f6443dbd84112c-b429f7b1939d4fc1f35718a4403a0d7a.ssl.cf1.rackcd... Certaines traductions (ou non-traductions) prêtent à débat, n'hésitez pas à commenter sur gerrit. :)
I've also added a tentative documentation about contributing, see https://384c64727f31e7a7ec3c-70aee045aa856a76767e0cd0433cf359.ssl.cf2.rackcd... My main concerns are the fact that the translation files' format is not exactly standard, which would make integration harder with other translation systems used by OpenDev; and how to ensure translations remain up to date as new features land in the zuul dashboard. I've proposed a solution for the latter in the doc, let me know what you think.
Finally, and not the least concern: this patch introduces a lot of changes to the dashboard, in a lot of files. If there are any ongoing GUI changes that should be merged in priority (I'm thinking maybe the migration to PF4: https://review.opendev.org/#/c/736225/ ), let's do it quickly because rebasing this one will not be fun!
On Tue, Jun 23, 2020 at 8:53 AM Andreas Jaeger aj@suse.com wrote:
On 22.06.20 21:05, Matthieu Huin wrote:
We can take this opportunity to expand this thread to discussing options for translating Zuul's website. Actually, if anybody has experience with translating rst documentation with sphinx, I'd be interested to hear about it, because I was eyeing that as a summer vacation project. :)
This is done today already, see the releasenotes translations for example on https://docs.openstack.org/releasenotes/nova/ .
Sphinx can use translation files to build translated docs and we use that for some documemts already. Translation happens in Zanata and then we have some infrastructure for translation, see also docs.openstack.org/i18n/
Andreas
Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
Matthieu Huin mhuin@redhat.com writes:
Since there was no opposition so far to react-redux-i18n, I went on and finished the translation coverage. French speakers: vous pouvez voir ce que ça donne ici: https://882d44f6443dbd84112c-b429f7b1939d4fc1f35718a4403a0d7a.ssl.cf1.rackcd... Certaines traductions (ou non-traductions) prêtent à débat, n'hésitez pas à commenter sur gerrit. :)
I think my biggest concern with this is how awkward the Translate component is to use. It looks like every string needs an identifier, so what's currently: <Link> Summary </Link>
Turns in to: <Link> <Translate value='buildContainer.build.summary' /> </Link>
In python, with gettext, the change is more like: print("Summary")
to: print(_("Summary"))
This is not only less typing, but critically, the developer doesn't need to create an identifier for the string (and ensure it's unique within the relevant namespace). This makes it easier for developers to perform maintenance on code, and increases the likelihood of compliance with the i18n standards (and therefore a higher rate of translatable strings).
Is there any kind of system like this for react? It seems at the very least, we should be able to do something like:
<Link> <t> Summary </t> </Link>
and have that work like gettext. Does something like that exist?
-Jim
On Fri, Jun 26, 2020 at 4:06 PM James E. Blair corvus@inaugust.com wrote:
I think my biggest concern with this is how awkward the Translate component is to use. It looks like every string needs an identifier, so what's currently: <Link> Summary </Link>
Turns in to: <Link> <Translate value='buildContainer.build.summary' /> </Link>
In python, with gettext, the change is more like: print("Summary")
to: print(_("Summary"))
This is not only less typing, but critically, the developer doesn't need to create an identifier for the string (and ensure it's unique within the relevant namespace). This makes it easier for developers to perform maintenance on code, and increases the likelihood of compliance with the i18n standards (and therefore a higher rate of translatable strings).
Is there any kind of system like this for react? It seems at the very least, we should be able to do something like:
<Link> <t> Summary </t> </Link>and have that work like gettext. Does something like that exist?
-Jim
All the examples I found used a namespace, but it turns out it is also possible to use regular strings, getting closer to what's familiar with gettext, see https://review.opendev.org/#/c/737290/6. It should also be possible to create a function _ as a shortcut to the <Translate /> component, but developers would still need to differentiate "pure" text strings (translated with the _ function) from translatable strings passed as components' properties (which need to be translated with the I18n.t function).
It also turns out tripleo-ui implemented i18n in a comparable way (but with another library): https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-i18n-support-for-j... and https://review.opendev.org/#/q/topic:bp/tripleo-ui-i18n-support-for-js+(stat...) The good news is that Zanata integration and using the existing i18n-related Zuul jobs for this shouldn't be too hard, should we want to go this way.
Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
participants (5)
-
Andreas Jaeger
-
corvus＠inaugust.com
-
Jeremy Stanley
-
Jimmy McArthur
-
Matthieu Huin