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?)
David
On 21 December 2015 at 10:45, Morten Olav Hansen <morte...@gmail.com> wrote:
> Hi
>
> Running with the latest 2.21, I was able to easily import this translation:
> {
> "translations": [
> {
> "objectUid": "iZuMXiwGIXd",
> "property": "name",
> "className": "OrganisationUnit",
> "locale": "no",
> "value": "By"
> }
> ]
> }
>
> 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:
> /api/organisationUnits/iZuMXiwGIXd?fields=id,displayName
>
> 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.
>
>
> --
> Morten
>
> On Sun, Dec 20, 2015 at 11:41 AM, Morten Olav Hansen <morte...@gmail.com>
> 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.
>>
>> --
>> Morten
>>
>> On Sun, Dec 20, 2015 at 10:59 AM, David Hagan <david.ha...@sagehagan.com>
>> wrote:
>>
>>> OK,
>>>
>>> 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 …
>>>
>>> api/organisationUnits?fields=name,displayName&locale=en&filter=level:eq:2
>>>
>>> correctly displays results:
>>>
>>> <organisationUnits>
>>> <organisationUnit name=“البحر الاحمر">
>>> <displayName>Red Sea</displayName>
>>> </organisationUnit> …
>>>
>>> AND
>>>
>>> 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:
>>>
>>> <organisationUnits>
>>> <organisationUnit name="Автономна Республіка Крим">
>>> <displayName>Avtonomna Respublika Krym</displayName>
>>> </organisationUnit>
>>>
>>> or (for locale=ru)
>>>
>>> <organisationUnits>
>>> <organisationUnit name="Автономна Республіка Крим">
>>> <displayName>Автономная Республика Крым</displayName>
>>> </organisationUnit>
>>>
>>> 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.
>>>
>>> David
>>>
>>>
>>> On 20 December 2015 at 09:11, Morten Olav Hansen <morte...@gmail.com>
>>> 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?
>>>>
>>>> --
>>>> Morten
>>>>
>>>> On Sun, Dec 20, 2015 at 8:59 AM, David Hagan <david.ha...@sagehagan.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.
>>>>>
>>>>> Cheers
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On 20 December 2015 at 07:10, David Hagan <david.ha...@sagehagan.com>
>>>>> wrote:
>>>>>
>>>>>> Ahhh-haaaa,
>>>>>>
>>>>>> Ok, a nice little gotcha to add to my little book of DHIS2
>>>>>> tips-for-newbies!
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 19 December 2015 at 23:32, Morten Olav Hansen <morte...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> --
>>>>>>> Morten
>>>>>>>
>>>>>>> On Sat, Dec 19, 2015 at 11:11 PM, David Hagan <
>>>>>>> david.ha...@sagehagan.com> wrote:
>>>>>>>
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>> I seem to be having no end of challenges with linking/viewing
>>>>>>>> imported translations for Organisational Units on the following
>>>>>>>> implementation:
>>>>>>>>
>>>>>>>> Version: 2.21
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> David Hagan
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>>>>> Post to : dhis2-users@lists.launchpad.net
>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp
