I’m not sure about the current standing when it comes to Android and translation (both UI and DB). I’m adding in Simen who should be able to help you.
On Mon, Dec 21, 2015 at 5:45 PM, David Hagan firstname.lastname@example.org wrote:
Thanks for that,
Yes, I can confirm that the API side of things, there were no problems … just on the UI side.
I’ve subsequently updated our build to Build revision: 20971 and the UI side of things is now performing as it should.
On a side note … we’ll be deploying multiple 7/10 inch Android devices to support the Android Tracker App to multi-lingual teams … how easy it to switch languages (database) on the Tracker App (is it tied to the logged in user and their settings or is there a separate setting on the device?)
On 21 December 2015 at 10:45, Morten Olav Hansen email@example.com wrote:
Running with the latest 2.21, I was able to easily import this translation:
The command I used was:
curl -X POST -d @translation.json -H “Content-Type: application/json” -u admin:district http://localhost:8080/api/metadata -v
The translated version was immediately available at:
As for the reporting tools, please be aware that there have been many updates in the last weeks, so please be sure to run the very latest version.
Also know that in the maintenance UI there might still be places where translation is not enabled, so please us know and we will fix it.
On Sun, Dec 20, 2015 at 11:41 AM, Morten Olav Hansen firstname.lastname@example.org wrote:
Ok, I will have a look tomorrow and report back. As for reporting/analytics tools, there have been a lot of backports, so you should be running the very latest 2.21.
On Sun, Dec 20, 2015 at 10:59 AM, David Hagan email@example.com wrote:
Thanks (if you think it is worth looking, I can give you a login to the development instance) …
A few more comparative details (and I hope I’m not doing something stupid with cache) to maybe help narrow down things …
On an instance hosting build version 20940 for Arabic-English … issuing an API call …
correctly displays results:
<organisationUnit name=“البحر الاحمر">
for the above also displays (when database locale is set to English in settings) the Org Unit english name in the ‘left hand tree’ during data-entry (but not in pivot table selection trees), but do show correctly on pivot table results etc.
On the instance in question (build version 20895) the same API call also correctly displays results:
Avtonomna Respublika Krym
or (for locale=ru)
Автономная Республика Крым
but for the UI for data-entry, or the organisation units App the language remains the default Ukrainian, though the event visulisor results show the correct locale equivalent for the org unit selected.
Perhaps we’ll go ahead and upgrade the instance in question to build 20940 to see if this resolves the UI display peculiarities to eliminate that possibility before you commit any time to this.
On 20 December 2015 at 09:11, Morten Olav Hansen firstname.lastname@example.org wrote:
Ok, let me have a look at this Monday and see if I can reproduce the issue.
After you import the translation, where do you check if they are working or not? in the web-api? data dictionary maintenance module? reporting tools?
On Sun, Dec 20, 2015 at 8:59 AM, David Hagan email@example.com wrote:
A further note to the self:
Don’t assume! I assumed the objectclass for the import file would be ‘organisationUnit’ … but no, it’s ‘OrganisationUnit’ … … and thus the apparent no-show through the UI.
Just a note though, if the objectless ‘doesn’t exist’ during an API import, perhaps the validation checks for the import should reject those items?
The other part of the challenge (seeing the org unit translations when you select the database locale ) hasn’t resolved itself even after a restart.
On 20 December 2015 at 07:10, David Hagan firstname.lastname@example.org wrote:
Ok, a nice little gotcha to add to my little book of DHIS2 tips-for-newbies!
On 19 December 2015 at 23:32, Morten Olav Hansen email@example.com wrote:
One gotcha you need to be aware of, is that we have an internal optimisation which is triggered if there are no translation available for a type, and this is checked on startup. So if you add a translation for a -new- type (i.e. adding translation to org units, and you had none before), you will need to restart your server.
On Sat, Dec 19, 2015 at 11:11 PM, David Hagan firstname.lastname@example.org wrote:
I seem to be having no end of challenges with linking/viewing imported translations for Organisational Units on the following implementation:
Build revision: 20895
We set this version up of a tri-language Ukrainian/Russian/English implementation (that is mobile-tracker focused).
We have imported the equivalent of States/Districts/Org Units in Ukrainian and were using the API to import the EN/RU translations for Name and Short Name for the organisation units.
The translations are visible in the Translation Table, but do not show-up when you click on the translation option through the UI for an organisational unit. I can go in and create a manual translation entry for one of the Organisational Units and it appears to all intent and purposes identical in form in the Translation table as the ones I loaded via the API.
I’m also having no luck (in this instance) with switching and viewing the database language locale for ‘manual’ translation entries for organisational units.
It doesn’t matter whether I clear DHIS side cache and/or browser-side cache or set up a clean browser interface after changing the database locales in my user settings.
Is there anything about this build revision that is problematic with linking/displaying translations for organisational units?
My next option is to patch this to the latest Build Revision.
Mailing list: https://launchpad.net/~dhis2-users
Post to : email@example.com
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp