Thanks Araz, crystal clear. So, waiting for 2.24 :)
Thanks
On Tue, Jun 14, 2016 at 10:09 AM, Araz Abishov wrote:
> Hi Jose and Morten,
>
> Since we are relying on display[*] properties in SDK and android apps, we
> will get translations as soon as api support will be there (if
Hi Jose and Morten,
Since we are relying on display[*] properties in SDK and android apps, we
will get translations as soon as api support will be there (if you are
running 2.24, it should not be a problem any more).
Best regards,
—
Araz Abishov,
Android developer, DHIS 2
University of Oslo
Hi again
I'm not sure how this is handled in the SDK, but unless they are using
translate=false, it should "just work". Of course they must be using
`displayName` etc, but probably they are already doing that (I'm sure Araz
can confirm if that's the case)
--
Morten Olav Hansen
Senior Engineer,
That's great! Happy to hear that! Thanks Morten,
So, do you know when it is going to be pusblished in the SDK as well? Is it
going to be introduced in the new SDK version?
Thanks
Jose
On Tue, Jun 14, 2016 at 6:06 AM, Morten Olav Hansen
wrote:
> Hi Jose
>
> We have
Hi Jose
We have re-implemented the way translations work in 2.24, so this should
not be a problem anymore, even nested field queries will be translated (as
long as the app is using displayName and not name), it will require a bit
more testing, but it should work fine
--
Morten Olav Hansen
Hi Araz, Morten,
I am reopening this old thread (sorry for that :) ), just to know if you
have some updates regarding the use of multilingual in the DHIS2-SDK (we
are mainly interested in the options of the optionsets). Have you had a
chance to work on it? Is this something that will come up
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
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.
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
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
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 wrote:
> Hi Jose and David,
>
> I just have a few questions to understand problem better:
>
> -
What he said :-)
We’d like at a minimum the display-names of the data-elements/option-sets
to respect the DHIS2 User database language setting … and a bonus would be
that the user can ’select’ from the available languages during login to the
App.
For prompts and such, I understand one just needs
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
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
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
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
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
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
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 wrote:
> Hi Morton - thanks for the clarification. Now that we know that we have
> what i think are the two critical
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
wrote:
> Hi
>
>
20 matches
Mail list logo