Firstly, let me thank you for all these suggestions, I completely agree with them, but even more, I think that we must take it into consideration, if we want to have really useable tool for in-page localization. Let me slightly open my ideas how to implement the concept of making translations locally, without internet connection to master server.
1. User, when doing any in-line translations on any pages within his http session, can immediately store all outputs, made him so far. In this case, bookmarklet engine, which works in his browser, will post new changeset to local server, which *do not require internet connection*. 2. The server, having corresponding API, will save new translations into corresponding message properties files. 3. In case of successfully saving new changeset, the person, who makes translations will be notified with corresponding messages that says: *"Thank you! Your translations have been succesfully saved to local server, but was not committed to the main server yet. If you want to commit them ..."* 4. Then translator can press *Commit local changes button*, which can be imperceptibly added onto the bottom strip with languages. Local server, which receives commit requests, will check the connection with *master OpenMRS server*. If the connection can be established, it will make something like svn diff of message properties files on both local and master servers. After creating the diff, local server will respond this diff in user-friendly format to client. Client may review it, correct any conflicts and approve commit operation. In fact, local server will send approved diff to master server, which will try to apply received changeset. In case of succeed, master sends corresponding aknowledge to local server and person, who made these translations, will be notified with success message. The idea of *distributed translations sharing* lays inside this concept. Because we can configure any OpenMRS server either as client or as master. But the description, given above, is very simplified summary of this idea. We also will need to take into consideration the identity of translators, to allow user to commit only his translations, but these are implementation details and we can find good workaround for this. Any ideas are appreciated and would help us find more agile solution together. Cheers, Mykola On Sun, Jan 29, 2012 at 12:29 AM, Andrew Kanter <[email protected]>wrote: > FYI, Andreas Kollegger worked on a module which basically replaced the > captions with their message.properties titles and made it easier to find > the terms which were not translated. However, I like the idea of seeing > them in context and be able to fix them in context as well. One caveat, it > is helpful to see translations in other languages at the time you are doing > your translation, as often times the level of specificity of the > translation is not the same and you can see better what was meant by seeing > it in a different language. Of course, if you are dev and know what the > text REALLY means, in your own language, then it is easier ;) > > Andy > > *-------------------- > Andrew S. Kanter, MD MPH > > - Director of Health Information Systems/Medical Informatics* > *Millennium Villages Project, Earth Institute, Columbia University* > *- Asst. Prof. of Clinical Biomedical Informatics and Clinical > Epidemiology* > *Columbia University* > > Email: [email protected] > Mobile: +1 (646) 469-2421 > Office: +1 (212) 305-4842 > Skype: akanter-ippnw > Yahoo: andy_kanter > > ------------------------------ > *From:* Burke Mamlin <[email protected]> > *To:* [email protected] > *Sent:* Saturday, January 28, 2012 1:13 PM > *Subject:* Re: [OPENMRS-DEV] OpenMRS In-page localization > > Great ideas! I've wanted to see this happen for a while > (TRUNK-1525<https://tickets.openmrs.org/browse/TRUNK-1525>). > As you think of solutions, please consider supporting (or being able to > eventually support) translation without the need for an internet connection > during translation (i.e., user can translate their local server without > being connected to the internet and then submit those translations later). > Although, any facility for in-page translations would be awesome. > > Coming from a Zope/Plone background, I wanted to evolve to where > developers could specify not only the code but also the default locale & > text both in web page tags and within the code, allowing for default > message bundles to be automatically generated and to make it even easier > for in-page translations. > > Cheers, > > -Burke > > On Sat, Jan 28, 2012 at 5:57 AM, Mykola Vorobey > <[email protected]>wrote: > > Hi devs, > > I would not mind to reveal my particular interest in implementing the idea > of in-page localization. As for me, this is correctly to give opportunity > for translators to see their translations precisely in context of the page. > When I was reading the wiki page for this > project<https://wiki.openmrs.org/display/projects/In-page+Localization+(Design+Page)>, > some ideas came to my mind and I'd like to share them with you right now. > > 1. Use bookmarklet <http://en.wikipedia.org/wiki/Bookmarklet> instead > of Firefox plugin. In my opinion it's not the best practice to set bounds > for potential translators which browser to use (apriori, it's his > prerogative). We can put this bookmarklet in the bottom of the page at > strip with languages. > 2. Allow translators *not only locally save their translations*, but > also *commit them to OpenMRS serve*r (just like many popular > translations services do, for instance Amanuens <http://amanuens.com/> or > Transifex <https://www.transifex.net/start/>). For this we can create > appropriate DWR service and post translations data using JQuery, for > example. > 3. As for issue of synchronization openmrs:message tags values content > with message.properties files (#2 and #3 tasks on wiki page of project), I > think it would not hurt, if we create corresponding ant targets, which will > be responsible for both these tasks. It will be great if we add antrun > plugin <http://maven.apache.org/plugins/maven-antrun-plugin/> to our > maven program object model to launch those targets from maven too. So, we > won't limit developer what build manager to use. > > Cheers, > Mykola > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
