dhis2-devs-core team mailing list archive

[Mark Polak <mark@xxxxxxxxx>]

Hey All,

I think writing it using both libraries would be a good trial as to see
which one fits us best.

Regarding format-js, i like that it is based on the standard (which i18next
is not, at least not the way it is integrated into the browser). However, i
do think that the ICU format for translations is more complicated than the
i18next format.
The program that Jason and i started out to solve was improvement of the
workflow for the translation process. This is something that format-js
might not solve as straightforward as i18next would. That does not mean
that the other benefits that it gives us are not worth considering, as the
second big benefit of format-js would be that it has date and number
formatting (i10n) included as well, which we also do not get with i18next.

So from a devs perspective it would probably be nice to use format-js. From
a translation workflow perspective i think it doesn't really matter what we
use, as long as it improves the workflow and we can automate some steps,
generate the source files and reduce the manual effort needed to get the
translations back into the apps. But it seems that format-js did not aim to
solve the problem that we initially set out to solve (and that they use
some other solutions to do that [1])

Also we have to figure out if the ICU format is supported by pootle or if
we need a translation step that creates a .po file from a ICU source, and
how to manage all the ICU source messages. As we thought it up with
i18next, we would extract the english source strings from the source code,
if we were to use a key/value based source file as the format-js examples
do, we would solve the problem of potentially unused strings/messages.

I think however it might be worth the effort to investigate if it is
possible to solve the workflow issues that we lack with format-js, as
ultimately the standard based approach will be the best bet for
maintainability. However, if we can not do this without investing
significant investments into writing the integrations ourselves, it might
not be worth it.

[1] https://github.com/yahoo/intl-messageformat/issues/94

Regards,

Mark

On Sat, May 14, 2016 at 7:25 AM, Morten Olav Hansen <morten@xxxxxxxxx>
wrote:

> Thanks for the writeup Jason, I don't have any particular strong feelings
> about i18next vs format-js (as I don't really know much about them). I do
> know that format-js is part of a ECMA standard [1], but maybe that is also
> true for i18next.
>
> Starting with a small app like cache cleaner sounds like a good idea, it
> could even be implemented using 2-3 different frameworks to learn about
> pros and cons.
>
> [1] http://www.ecma-international.org/ecma-402/1.0/
>
> --
> Morten Olav Hansen
> Senior Engineer, DHIS 2
> University of Oslo
> http://www.dhis2.org
>
> On Sat, May 14, 2016 at 12:15 PM, Jim Grace <jim@xxxxxxxxx> wrote:
>
>> Thanks for the background, Jason. That's very helpful.
>> On May 14, 2016 7:08 AM, "Jason Pickering" <jason.p.pickering@xxxxxxxxx>
>> wrote:
>>
>>> Hi Morten,
>>> Thanks for your comments. I realize everyone is busy. This is an attempt
>>> to make us less busy though, by simplifying and improving the translation
>>> workflow. As you have probably seen even recently on the list, there are
>>> issues with translations in the apps (beyond the lack of actually having
>>> the translations themselves). If we are going to support i18n, then we
>>> should probably try and do it right.
>>>
>>> Anyway, for the other two frameworks, I think Mark would be best
>>> positioned to comment on them, but one of the reasons why i18next looked
>>> good was because of the other tools which surround it. Devs are not going
>>> to write the translations, so we need to be able to get the translations
>>> out of the apps and into something which translators can work with,
>>> preferably not JS/Java source code. Property files work OK, but have issues
>>> (duplicates and plurals being two I can think of). PO (gettext) files seem
>>> to work very well with many different translation tools mentioned in the
>>> document. That is really why Mark and I thought this particular framework
>>> looked good.
>>>
>>> Having said that, I think the principles of the different frameworks are
>>> quite similar. What is probably more important is that we as a community
>>> try and agree on a standard of how the translations are handled. If
>>> individual app devs want to use this framework or that framework, I guess
>>> that is really up to them. But having a single source of truth for the
>>> translations used across the platform is something we should try and
>>> achieve I think.
>>>
>>> The other thing I will say is that both of these frameworks also deal
>>> with localization, such as commas in formatted numbers and date-time
>>> formats. I did not really even start to address that issue, as its a bigger
>>> one, such as support for RTL languages. Right now, Mark and I wanted to try
>>> and simplify the i18n workflow of the translations only, but keeping
>>> localization in mind is also of course important.
>>>
>>> Mark and I thought we would try (when we get time) with the cache
>>> cleaner app, as its very simple. This would just to be to test the workflow
>>> end-to-end, from coding to translation and then back again.
>>>
>>> Regards,
>>> Jason
>>>
>>>
>>> On Fri, May 13, 2016 at 11:00 PM, Jim Grace <jim@xxxxxxxxx> wrote:
>>>
>>>> Hi Jason and Mark,
>>>>
>>>> Thanks for putting all this together. It looks reasonable to me (though
>>>> I don't know much about it.) I'd also be interested in your answer to
>>>> Morten's question about react-intl + format-js.
>>>>
>>>> Cheers,
>>>> Jim
>>>>
>>>>
>>>> On Fri, May 13, 2016 at 8:52 PM, Morten Olav Hansen <morten@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hi Jason
>>>>>
>>>>> I'm sorry, but I think it's more about the lack of time to answer,
>>>>> it's been a very busy week. Now we have a "mini" holiday in Norway, so will
>>>>> try and read it and reply.
>>>>>
>>>>> My immediate thoughts is that any kind of improvement is good.
>>>>>
>>>>> I'm a bit surprised you didn't suggest something like react-intl +
>>>>> format-js though, seems to be very popular among the react-js community..
>>>>> maybe i18nnext is more similar to our current gettext/po system?
>>>>>
>>>>> Just talking about VN locally, what they want is proper input format
>>>>> (comma vs punctum etc), but I think there is already something happening
>>>>> there (not sure if it's client side only, or also on server, analytics etc,
>>>>> at least 2.24 will have some kind of option for output).
>>>>>
>>>>> --
>>>>> Morten Olav Hansen
>>>>> Senior Engineer, DHIS 2
>>>>> University of Oslo
>>>>> http://www.dhis2.org
>>>>>
>>>>> On Fri, May 13, 2016 at 11:37 PM, Jason Pickering <
>>>>> jason.p.pickering@xxxxxxxxx> wrote:
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> Since there has been no feedback yet, I assume this means we are
>>>>>> clear to proceed.
>>>>>>
>>>>>> Mark and I will coordinate the refactor and inform the various app
>>>>>> developers of the new procedure.
>>>>>>
>>>>>> Regards,
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, May 11, 2016 at 10:49 AM, Jason Pickering <
>>>>>> jason.p.pickering@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> First, apologies for cross-posting. I was not sure who was on which
>>>>>>> list.
>>>>>>>
>>>>>>> Mark and I have put together a review document regarding
>>>>>>> translations and localization. This was spurred in part by my recent
>>>>>>> interaction with the i18n community who produces the Pootle software, which
>>>>>>> is used for the DHIS2 Translation server
>>>>>>> <http://translate.dhis2.org/> and the challenges we face in getting
>>>>>>> translations into the software.
>>>>>>>
>>>>>>> I think we can all agree that the current state of the translations
>>>>>>> is pretty poor. Much of the software is at best partially translated.
>>>>>>> Translations typically are an effort taken by particular implementers, and
>>>>>>> when the realize how much work it is, they typically stall. Certain
>>>>>>> translations such as Arabic were performed to almost completion at the
>>>>>>> time, but have since not regularly been updated along with the source code.
>>>>>>>
>>>>>>>
>>>>>>> I think we can do better, and Mark and I put this document together
>>>>>>> to suggest some possible way forward to improve how we internationalize the
>>>>>>> software and hopefully bring in the broader localization community into the
>>>>>>> project.
>>>>>>>
>>>>>>> Please have a look, edit and comment here
>>>>>>>
>>>>>>>
>>>>>>> https://docs.google.com/document/d/1u0YhRZD2Q3F8p6VCsz7dXdZxJL45R0qsEfsNc0OCJYs/edit?usp=sharing
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Jason
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jason P. Pickering
>>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>>> tel:+46764147049
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason P. Pickering
>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>> tel:+46764147049
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jim Grace
>>>> Core developer, DHIS 2
>>>> HISP US Inc.
>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>
>>>
>>>
>>>
>>> --
>>> Jason P. Pickering
>>> email: jason.p.pickering@xxxxxxxxx
>>> tel:+46764147049
>>>
>>
>
> --
> Mailing list: https://launchpad.net/~dhis2-devs-core
> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs-core
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Regards,


Mark Polak
Software developer, DHIS 2
University of Oslo
http://www.dhis2.org <https://www.dhis2.org/>
mark@xxxxxxxxx