(moving this discussion of translation issues & the custommessages module to the dev list in case others are interested)
Mike, I agree with you & Mykola, that the target for Mykola's in-page translation GSoC project would fitly nicely as an enhancement to the custommessages module – i.e., leveraging the existing functionality to store customized messages in the database and introduce the ability to make those customizations directly within the pages of the web application. Since we are storing messages in the database, the need to distinguish module-specific keys from core keys is less of an issue. Originally, we were imagining updating the message bundles, which means that we would need to know which properties file (and where it was) to update it. Changing to a read-only mode (where Spring messaging handles getting the right message from the right module or core properties file) and our writes all go to the database, makes this issue moot… at least until we get to exporting, where it would be nice to export messages in a format that could easily be used to update/replace properties files within core or module(s). There are several reasons for creating an openmrs:message tag to replace use of the spring:message tag. Here are the main ones: - Provide built-in support for our in-page translation mode (tag will render a special span tag when translation mode is turned on… something like this <http://jsfiddle.net/burke/QZRJL/embedded/result/>) - Allow default messages to be supplied in place without having to escape HTML entities - Allow the locale for the default message to be specified (so the default message does not *have* to be in the en locale) Cheers, -Burke On Thu, May 17, 2012 at 4:37 AM, Mykola Vorobey <vorobeymyk...@gmail.com>wrote: > Hi, Mike, > >> >> - Not sure what you mean by "support for other modules, ability to >> distinguish between core and module messages". The custommessages module >> stores all of it's custom translations, whether for a core-provided >> message >> or a module-provided message in the same table already. Is there >> something >> that is missing that you would need to add in here? >> >> Actually, the the distinguishing between affiliation of any message to > certain module or core must be performed on basis of module naming > conventions. And if conventions are not followed, then the decision must be > done using special attribute of *openmrs:message* tag, that overrides > message inference. > >> >> - Export functionality - just so you are aware, custommessages >> already has some capabilities to export messages. I'd be happy to see >> enhancements to this, but curious as to what you have in mind. >> >> I meant adding of ability for user to export all in-place edits, that > made (or updated, or both) by him using this module. > > >> - I think a new openmrs:message tag is a great idea, and in general I >> think we would have done better by wrapping all of the tags we use in >> corresponding openmrs tags to give us the ability to customize these as >> needed. That being said, the spring:message tag already supports a >> default >> translation - I believe you use the "text" attribute of the tag. Is this >> what you are referring to, or were other capabilities needed here? >> >> Not exactly, we just wanted to have default text as tag body, because > Burke was a bit concerned of need to escape HTML specific entities &, ", <, > and >, when using "text" attribute. In the rest, I do believe, that we > understand each other right. > > Thanks, for discussion! I would like to know if anyone of CCs has opinion > on on this, so we can review any outstanding questions as well? > > Best, > Mykola > On Thu, May 17, 2012 at 10:28 AM, Michael Seaton <msea...@pih.org> wrote: > >> ** >> Hi Mykola, >> >> This sounds good to me - I'd value these great additions to >> custommessages. A few minor comments: >> >> - Not sure what you mean by "support for other modules, ability to >> distinguish between core and module messages". The custommessages module >> stores all of it's custom translations, whether for a core-provided >> message >> or a module-provided message in the same table already. Is there >> something >> that is missing that you would need to add in here? >> - Export functionality - just so you are aware, custommessages >> already has some capabilities to export messages. I'd be happy to see >> enhancements to this, but curious as to what you have in mind. >> - I think a new openmrs:message tag is a great idea, and in general I >> think we would have done better by wrapping all of the tags we use in >> corresponding openmrs tags to give us the ability to customize these as >> needed. That being said, the spring:message tag already supports a >> default >> translation - I believe you use the "text" attribute of the tag. Is this >> what you are referring to, or were other capabilities needed here? >> >> Adding in these features to custommessages, mavenizing the module, etc is >> fine with me. I'm excited to see it evolve! >> >> Cheers, >> Mike >> >> >> >> On 05/17/2012 03:13 AM, Mykola Vorobey wrote: >> >> Thanks, Mike, for so wide response. >> >> Yes, you are right, that it would be just kind of alternative UI built >> on top of your module. We are planning to do a bunch of work >> on this actually inside *custommessages*module project. It will actually >> include introducing of: >> >> - new mode for rendering OpenMRS pages with text messages, that can >> be translated in-line - i.e. *translate mode* >> - functionality that allows user to toggle translate mode on/off. >> - corresponding *Global Property* for handling this mode >> - adding new extension point within core *footerFull.jsp* for placing >> toggling button into and implementing this inside module >> - new access privilege for managing translations >> - ability to edit “translatable” messages in place (actually, it >> would be a kind of javascript engine) >> - DWR translation service to be used for handling outcomes of >> in-place editing >> - support for other modules, ability to distinguish between core and >> module messages, so it would require some changes into service and >> data access tiers in order to handle modules messages persisting alongside >> with core ones >> - enhanced export functionality (i.e. add ability for user to export >> translations, >> which he has already done so far) >> - may be some enhancements with project codebase, i.e. mavenize it, >> etc >> >> Alongside with this, we are going to add into core new *openmrs:message* tag >> with corresponding *OpenmrsMessageTag *class, which wraps existing >> spring:message tag and adds ability to put default translation within tag >> body. Thereafter we need to provide translation capability for * >> OpenmrsMessageTag* class within project module. So, this is quite >> convenient to have such thing as "message code mode", so we can develop >> this idea further in order to suit our needs in this stuff. >> >> I would definitely like to know your opinion about possibility and >> technical details of adding above mentioned features into *custommessages >> * project. So, please, share your feedback on this, we appreciate it. >> >> Cheers, >> >> > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
