dhis2-users team mailing list archive
-
dhis2-users team
-
Mailing list archive
-
Message #08871
Re: Viewing/linking imported Translations of Organisational Units
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.hagan@xxxxxxxxxxxxx>
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 <mortenoh@xxxxxxxxx>
> 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.hagan@xxxxxxxxxxxxx>
>> 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.hagan@xxxxxxxxxxxxx>
>>> 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 <mortenoh@xxxxxxxxx>
>>>> 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.hagan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Follow ups
References