Re: Custommessages module

classic Classic list List threaded Threaded
2 messages Options
Burke Mamlin-2 Burke Mamlin-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custommessages module

(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)
  • 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 <[hidden email]> 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 <[hidden email]> 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 custommessagesmodule 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,



[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custommessages module

Hi Burke,

From what I recall, the default export feature currently available in the custommessages moudule will allow you to choose from the list of available locales and export all existing messages (both those that came from the properties files and those customized by the module).  So you can just export the messages in a locale, this will construct a file called messages_xxx.properties, and you should just be able to take this and replace the appropriate one in core.  A nice feature to add would certainly be able to only export those from core or a particular module.

I definitely support the creation of openmrs tags that wrap any use of existing spring or jstl tags, so that we can expand on any of their functionality as needed without re-writing our entire webapp...

Mike


On 05/18/2012 04:49 PM, Burke Mamlin wrote:
(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)
  • 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 <[hidden email]> 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 <[hidden email]> 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 custommessagesmodule 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,



[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Loading...