Internationalization of Web API response info / conflicts?

Support - Assistance technique
1

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

2

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

···

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

–
Morten

3

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

···

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

4

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

···

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

–
Morten

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

5

Hi Morten,

These are the places where we’re seeing inconsistencies:

  • /api/sqlViews//execute POST: returns String - “SQL view created”
  • /api/sqlViews//data GET: exception in tomcat logs returns HTML error page (eg: if view has not been executed)
  • /api/events POST: returns importSummaries in JSON (inconsistent with other api calls where importCount, importConflicts, conflicts etc are at root level)
  • /api/events PUT: returns String - “Event updated…”
  • /api/trackedEntityIntances POST: returns ‘reference’, not ‘lastImported’ in JSON
  • /api/trackedEntityInstances POST: exception in tomcat logs returns HTML error page
  • There are also many api calls for assignments i.e.
  • /api////
    That return 204 (no body). Is this intentional/expected behaviour?
    Thanks,

Lorill

···

On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

–
Morten

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

6

Hi

I have a couple of additions:

  • Filtering results does not always retrieve the record you’re after unless you specify paging=false (or it’s on the first page)

  • Some entties use paging=false, others use skipPaging=true

Thanks

Alan

···

On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees lcrees@2paths.com wrote:

Hi Morten,

These are the places where we’re seeing inconsistencies:

  • /api/sqlViews//execute POST: returns String - “SQL view created”
  • /api/sqlViews//data GET: exception in tomcat logs returns HTML error page (eg: if view has not been executed)
  • /api/events POST: returns importSummaries in JSON (inconsistent with other api calls where importCount, importConflicts, conflicts etc are at root level)
  • /api/events PUT: returns String - “Event updated…”
  • /api/trackedEntityIntances POST: returns ‘reference’, not ‘lastImported’ in JSON
  • /api/trackedEntityInstances POST: exception in tomcat logs returns HTML error page
  • There are also many api calls for assignments i.e.
  • /api////
    That return 204 (no body). Is this intentional/expected behaviour?
    Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

–
Morten

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

7

Hi

Most of this should now be fixed, please note that also our import summary(ies) are now wrapped in a WebMessage (check responseType to know which payload was sent)

Regarding the filtering bug, that was fixed a while back.

We know about the difference in paging parameters, but we will not change it right now. I think you should be ok if you follow this simple rule 1) if its metadata use paging=true/false 2) if its data use skipPaging=true/false

Thanks for reporting the issues.

···

–
Morten

On Fri, Jun 19, 2015 at 3:56 AM, Alan Hill ahill@2paths.com wrote:

Hi

I have a couple of additions:

  • Filtering results does not always retrieve the record you’re after unless you specify paging=false (or it’s on the first page)
  • Some entties use paging=false, others use skipPaging=true

Thanks

Alan

On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees lcrees@2paths.com wrote:

Hi Morten,

These are the places where we’re seeing inconsistencies:

  • /api/sqlViews//execute POST: returns String - “SQL view created”
  • /api/sqlViews//data GET: exception in tomcat logs returns HTML error page (eg: if view has not been executed)
  • /api/events POST: returns importSummaries in JSON (inconsistent with other api calls where importCount, importConflicts, conflicts etc are at root level)
  • /api/events PUT: returns String - “Event updated…”
  • /api/trackedEntityIntances POST: returns ‘reference’, not ‘lastImported’ in JSON
  • /api/trackedEntityInstances POST: exception in tomcat logs returns HTML error page
  • There are also many api calls for assignments i.e.
  • /api////
    That return 204 (no body). Is this intentional/expected behaviour?
    Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

–
Morten

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

8

Hi Morten

Thanks for the information.

Regarding the filtering bug, do you know which version/build this was fixed in? I am still seeing the issue in 2.20-SNAPSHOT build #19473

Kind regards

Alan

···

On Tue, Jul 7, 2015 at 9:35 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

Most of this should now be fixed, please note that also our import summary(ies) are now wrapped in a WebMessage (check responseType to know which payload was sent)

Regarding the filtering bug, that was fixed a while back.

We know about the difference in paging parameters, but we will not change it right now. I think you should be ok if you follow this simple rule 1) if its metadata use paging=true/false 2) if its data use skipPaging=true/false

Thanks for reporting the issues.

–
Morten

On Fri, Jun 19, 2015 at 3:56 AM, Alan Hill ahill@2paths.com wrote:

Hi

I have a couple of additions:

  • Filtering results does not always retrieve the record you’re after unless you specify paging=false (or it’s on the first page)
  • Some entties use paging=false, others use skipPaging=true

Thanks

Alan

On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees lcrees@2paths.com wrote:

Hi Morten,

These are the places where we’re seeing inconsistencies:

  • /api/sqlViews//execute POST: returns String - “SQL view created”
  • /api/sqlViews//data GET: exception in tomcat logs returns HTML error page (eg: if view has not been executed)
  • /api/events POST: returns importSummaries in JSON (inconsistent with other api calls where importCount, importConflicts, conflicts etc are at root level)
  • /api/events PUT: returns String - “Event updated…”
  • /api/trackedEntityIntances POST: returns ‘reference’, not ‘lastImported’ in JSON
  • /api/trackedEntityInstances POST: exception in tomcat logs returns HTML error page
  • There are also many api calls for assignments i.e.
  • /api////
    That return 204 (no body). Is this intentional/expected behaviour?
    Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

–
Morten

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

9

Hi

In which endpoints do you see this? I have fixed it in the data element operand endpoint, but there could be others also

···

–
Morten

On Thu, Jul 9, 2015 at 12:23 AM, Alan Hill ahill@2paths.com wrote:

Hi Morten

Thanks for the information.

Regarding the filtering bug, do you know which version/build this was fixed in? I am still seeing the issue in 2.20-SNAPSHOT build #19473

Kind regards

Alan

On Tue, Jul 7, 2015 at 9:35 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

Most of this should now be fixed, please note that also our import summary(ies) are now wrapped in a WebMessage (check responseType to know which payload was sent)

Regarding the filtering bug, that was fixed a while back.

We know about the difference in paging parameters, but we will not change it right now. I think you should be ok if you follow this simple rule 1) if its metadata use paging=true/false 2) if its data use skipPaging=true/false

Thanks for reporting the issues.

–
Morten

On Fri, Jun 19, 2015 at 3:56 AM, Alan Hill ahill@2paths.com wrote:

Hi

I have a couple of additions:

  • Filtering results does not always retrieve the record you’re after unless you specify paging=false (or it’s on the first page)
  • Some entties use paging=false, others use skipPaging=true

Thanks

Alan

On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees lcrees@2paths.com wrote:

Hi Morten,

These are the places where we’re seeing inconsistencies:

  • /api/sqlViews//execute POST: returns String - “SQL view created”
  • /api/sqlViews//data GET: exception in tomcat logs returns HTML error page (eg: if view has not been executed)
  • /api/events POST: returns importSummaries in JSON (inconsistent with other api calls where importCount, importConflicts, conflicts etc are at root level)
  • /api/events PUT: returns String - “Event updated…”
  • /api/trackedEntityIntances POST: returns ‘reference’, not ‘lastImported’ in JSON
  • /api/trackedEntityInstances POST: exception in tomcat logs returns HTML error page
  • There are also many api calls for assignments i.e.
  • /api////
    That return 204 (no body). Is this intentional/expected behaviour?
    Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

–
Morten

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

10

Hi Morten…apologies for the delay in replying.

I am still seeing this with

/api/trackedEntityAttributes

2.20-SNAPSHOT

Build revision: 19647

I will let you know if I encounter any others.

Regards

Alan

···

On Wed, Jul 8, 2015 at 11:06 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

In which endpoints do you see this? I have fixed it in the data element operand endpoint, but there could be others also

–
Morten

On Thu, Jul 9, 2015 at 12:23 AM, Alan Hill ahill@2paths.com wrote:

Hi Morten

Thanks for the information.

Regarding the filtering bug, do you know which version/build this was fixed in? I am still seeing the issue in 2.20-SNAPSHOT build #19473

Kind regards

Alan

On Tue, Jul 7, 2015 at 9:35 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

Most of this should now be fixed, please note that also our import summary(ies) are now wrapped in a WebMessage (check responseType to know which payload was sent)

Regarding the filtering bug, that was fixed a while back.

We know about the difference in paging parameters, but we will not change it right now. I think you should be ok if you follow this simple rule 1) if its metadata use paging=true/false 2) if its data use skipPaging=true/false

Thanks for reporting the issues.

–
Morten

On Fri, Jun 19, 2015 at 3:56 AM, Alan Hill ahill@2paths.com wrote:

Hi

I have a couple of additions:

  • Filtering results does not always retrieve the record you’re after unless you specify paging=false (or it’s on the first page)
  • Some entties use paging=false, others use skipPaging=true

Thanks

Alan

On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees lcrees@2paths.com wrote:

Hi Morten,

These are the places where we’re seeing inconsistencies:

  • /api/sqlViews//execute POST: returns String - “SQL view created”
  • /api/sqlViews//data GET: exception in tomcat logs returns HTML error page (eg: if view has not been executed)
  • /api/events POST: returns importSummaries in JSON (inconsistent with other api calls where importCount, importConflicts, conflicts etc are at root level)
  • /api/events PUT: returns String - “Event updated…”
  • /api/trackedEntityIntances POST: returns ‘reference’, not ‘lastImported’ in JSON
  • /api/trackedEntityInstances POST: exception in tomcat logs returns HTML error page
  • There are also many api calls for assignments i.e.
  • /api////
    That return 204 (no body). Is this intentional/expected behaviour?
    Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

We have started changing some of endpoints already, if you e.g. try to get a invalid data-element /api/dataElements/abc123 you will see the new output format (xml and json supported, json is default). I have not started changing the import conflict format yet, and it probably will not be changed for 2.20, I’m hoping to start a rewrite of the importer in 2.21, and the change of response format would then end up being in that release.

Besides the import conflicts, if you are still seeing plain text error messages anywhere, please report back to me and I will replace them with a proper message.

–
Morten

On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees lcrees@2paths.com wrote:

Thanks Morten.

On a related note, have you defined how you will be changing the response messages yet? We’ve written a rudimentary response message parser as part of our app because we get quite inconsistent results from the various web api calls. EG: some responses return “conflicts” whereas others return “importConflicts”. Also we consistently ask for the response in JSON yet some responses return HTML regardless which makes parsing the responses difficult.

Knowing the changes you have planned will be helpful as it could potentially break the way we’re currently parsing the results.

By the way, we’re working off 2.20 snapshot.

Thanks,

Lorill

On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

No, this is not currently supported. We might support it in a future release, as we are changing our responses messages a bit in 2.20/2.21.

–
Morten

On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees lcrees@2paths.com wrote:

Hi All,

Is it possible to receive messages back from the web api in other languages? Specifically if there are import conflicts we would like to give these messages back to the user in their preferred language.

Thanks,

Lorill

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp