I don’t think we will be able to use that, since android SDK is built around
“standalone" API resources, so we need to come up with something different. At
least we will try to query each resource separately to get translations and
then combine it with results of “nested” query. If that approach will cause
performance problems, then we can try to use metadata endpoint as alternative
for retrieving translations.
Best Regards,
Araz Abishov
On February 11, 2016 at 1:07:58 PM, Morten Olav Hansen ([email protected]) wrote:
Sure, that makes sense. I'm actually adding a new endpoint for 2.23 which could
potentially help you, basically its a combination of all our endpoints, and the
main purpose is to use it for metadata export (for moving between servers) but
it can also be used for these kinds of optimized gets.
Some examples would be:
/api/metadata/export?dataElements=true&programs=true&programStages=true&dataElements:filter=id:in:[1,2,3,4]&dataElements:fields=displayName&programs:filter=id:eq:123&programs:fields=displayName
Etc etc.. you get the idea. I don't currently do translation there, but we
might want to look into that.
On Thu, Feb 11, 2016 at 7:01 PM, Araz Abishov <[email protected]> wrote:
Hi Morten,
The problem for us is mostly in the way how we are structuring requests (we are
using fields property in order to retrieve nested objects like dataelements
from program stages). As you said before, nested properties are not translated
due to potential performance problems on server. In order to workaround this we
will have to make separate requests to each API resource, which can result in
performance problem on mobile devices.
We are using displayName, displayFormName fields in objects starting from
v2.20, but they don't contain translation because of aforementioned reason.
Best Regards,
Araz
On Feb 11, 2016 12:46 PM, "Morten Olav Hansen" <[email protected]> wrote:
Hi Araz
Are you using the normal web-api for your requests? if so, many of these things
would be automatic on your end, just make sure you use displayName,
displayShortName, displayDescription, and displayFormName instead of name,
shortName, description and formName. Changing these should be backwards
compatible for several releases (given the proper field filter) and would give
proper translation from about release 2.20.
Of course the UI is another matter entirely, but all our endpoints should have
translation support enabled by default (unless you are saying translate=false
in your requests)
--
Morten
On Thu, Feb 11, 2016 at 6:42 PM, Araz Abishov <[email protected]> wrote:
Hi Rodolfo, David and Jose,
In order to add translation support with current web API implementation in
mind, we have to restructure legacy SDK in intrusive way and it will take a lot
of time and effort. In order to avoid “hacks”, we will have to wait for full
API translation support. We also will be looking for other possible solutions
in new version of SDK, I will keep updating you on changes.
Best Regards,
Araz Abishov
On February 10, 2016 at 8:53:20 AM, Rodolfo Melia ([email protected]) wrote:
Yes, sdk - just waking up.
On Wednesday, 10 February 2016, Jose Garcia Muñoz <[email protected]> wrote:
I think Rodolfo is referring to the SDK... Yes... with the form names and
option names translated we are ok...
On Wed, Feb 10, 2016 at 8:37 AM, Rodolfo Melia <[email protected]> wrote:
Hi Morton - thanks for the clarification. Now that we know that we have what i
think are the two critical translations in the API, how difficult would it be
to add the concept of multilingual to the APK ?
On Wednesday, 10 February 2016, Morten Olav Hansen <[email protected]> wrote:
Hi
Translated form names have been available under "displayFormName" for a long
time, I have added code to 2.22 and trunk to also translate options when
requesting a optionset (by id or collection). we can't do this for all objects,
as its a quite heavy operation, normally we only translate a single object or a
collection of objects
--
Morten
On Tue, Feb 9, 2016 at 11:48 PM, Rodolfo Melia <[email protected]> wrote:
It will be great if we can prioritise the metadata to be multilingual in the
API. We already know how to translate the Android UI, by generating our own
build.
I'm copying Morton to see if he can give us an idea of when the API would be
able to return the Form Name and Options in multilingual format. It is critical
for many of the implementations that we have in the pipeline in Asia - we need
the analytics in English, but the data collection, using android, in the local
language.
Rodolfo Meliá
On 9 February 2016 at 14:42, Araz Abishov <[email protected]> wrote:
Unfortunately, translation of metadata/data is not completely supported in API
due to some implementation complexities in the core, so we still don’t know
when exactly we will be able to implement multilingual support for android apps.
What we can do is additional setting for choosing language in application
preferences (but it will work only for UI prompts). In feature, when API will
be completely supporting translations, we will be able seamlessly integrate
support for it in android apps.
Best Regards,
Araz Abishov
On February 9, 2016 at 3:21:00 PM, Jose Garcia Muñoz ([email protected]) wrote:
Hi Araz,
I am talking about metadata (dataelements, optionsets, etc...). We don't have
problems with the user interface...
Thanks Araz
On Tue, Feb 9, 2016 at 3:15 PM, Araz Abishov <[email protected]> wrote:
Hi Jose and David,
I just have a few questions to understand problem better:
- Are we talking about translation of application prompts or translation of
metadata/data?
- Do you want user to be able to switch languages in user interface? (a
setting which allows to do that)
Best Regards,
Araz Abishov
On February 9, 2016 at 1:48:51 PM, David Hagan ([email protected])
wrote:
Afternoon Jose,
I second the question!
Actually, I’ve had this conversation on another thread over the new-year break
as we have a similar requirement (English, Russian, Ukrainian) … we’re making
do with one language at the moment, but the next iteration cycle of the App
really needs the user to be able to switch languages.
David
On 9 February 2016 at 13:32, Jose Garcia Muñoz <[email protected]> wrote:
Dear Simen, devs,
some months ago we started a conversation with you to know if the DHIS2-SDK is
supporting multilingual or not? The answer was:
"unfortunately there isn't very good support for multilingual in the SDK yet.
It's actually not that much work we just haven't prioritized it yet so it could
be made available without too much trouble... There is a bit of work that has
do be done on the server side to update the web API. Unfortunately I would have
to say that it likely would come in 2016, but when is unknown"
Do you have any updates? was the DHIS2 web API updated? If not, when can we
expect that? 2.23?
It is becaming some kind of urgent now because we plan to roll-out different
android apps in different countries (speaking French, English, Spanish,
Portuguese)..
Please, let us know if you have some more information to share.
Thanks
Jose
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
--
Rodolfo Meliá
Principal | [email protected]
Skype: rod.melia | +44 777 576 4090 | +1 708 872 7636
www.knowming.com
--
Rodolfo Meliá
Principal | [email protected]
Skype: rod.melia | +44 777 576 4090 | +1 708 872 7636
www.knowming.com
--
Morten
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp