Since the introduction of the new reporting application, it seems that the menu items for the app are no longer translated - we’re using French. I assume the data is available since it had been translated previously and I don’t think it has changed.
We have users complaining that they are unable to understand the UI since our upgrade and unfortunately we aren’t in a position to revert back to 2.32
Is there a target date to have the translations implemented in the newer versions (2.33 is what we’re using)? If not, is there a relatively painless way to implement them ourselves - I assume we’d have to fork the repo and implement them. If I’m not mistaken, the new UI for the app is done using React.
Or… first prize… Is there a way to simply include the old reporting app perhaps? Some of the reports are broken in the new app for us as well.
Thanks for bringing this to our attention. We don’t have full French translations for the reports app, but we do have some, and you are correct; they are not being displayed. I’ve raised this problem as a bug in Jira and informed our dev team.
Unfortunately, there is no simple way to include the old reporting app. In principle there is a way to fork the version and include more translations, but as none are currently being pulled into the app that is not applicable in this case. We will have to get this prioritised for a future patch release.
Thanks Phil. Unfortunately on our end it’s become an urgent issue with the majority of the field based staff being proficient in French and Creole. For the existing French translations, are they the same as the old app?
It’s very difficult for us to turn around a new patch very quickly, so the formal fix may still be a month or two away, but there are a couple of options open to you.
First, to answer your last question, the translations aren’t all the same as the old app. There are 118 missing string translations currently; which could probably be completed quite quickly by the right translator.
We started looking into the app today, and we should be able to fix it in the next couple of days. If we can get the additional translations in too, then you will then have the following options for getting an early fix:
You could take a nightly build of 2.33.
We call these “canary” builds, and we don’t recommend their use in production. They have not been through the regression testing that we apply to patch releases, so there is more risk of bugs/regressions. It is important that you are aware of those risks and accept them, performing your own testing accordingly, if you decide to use a canary build.
If you are comfortable with the build process. You can rebuild your existing version with the new Reports App.
This is the fork option that you considered above. Basically, you could build exactly the version that you are running now, but a very small change before building would allow you to pull the newest version of the Reports App. Basically, it would be like taking the canary build of the Reports App while keeping everything else the same; therefore much lower risk.
If the above are feasible for you and you would like more support, let me know.
Also, if you have staff who could support with the translations, I can provide access to the translation platform and some tips on how to take advantage of tools like machine translations.
I’ve worked on the translations bug that @phil reported and my fix is currently under review. It should solve the structural issue we had in the reports-app with translations. If we still encounter any untranslated strings after this fix is deployed, it will just be a) a hardcoded string, or b) a translatable string for which no translation has been made available yet. Both these type of problems are easy to solve.
If everything goes according to plan, this fix will be merged to master later on today.
Some of the reports are broken in the new app for us as well.
It would be great if you could provide some more information about the types of problems you have encountered with these reports. The HTML based reports in the new reports-app are a little tricky because we essentially have to create a standalone web-page in an iframe that is served from a React app. What is happening in the report-html is completely up to the creator of the template file, and we don’t know what type of CSS & JavaScript assets are required for a given templates to function correctly. We started by only including jQuery and dhis2.utils as JavaScript assets in the iframe, but it was recently brought to our attention that some reports do require other assets (previously available via the struts HTML template) to function correctly.
I suspect the reports that were broken in your instance were also suffering from missing assets, but it would be very useful to have this confirmed.
I’ve recently worked on quite a lot of fixes which should help solve problems with HTML based reports, so it could even be that some of the broken reports are working in the latest version already.
Hi guys, thanks for the prompt responses, really appreciate it. I will revert with the specifics of the broken reports - I think the original data forms have some custom markup that was done to improve layout and that may be related. That said, I’m keen to see how the new reports function when the fix is available.
Hi @hendrik here are some examples of formatting issues in the report output (obfuscation is intentional) - notice the apparently random font styles in the numbers:
