Thanks Josh for the clarification. It sounds like the idea of translations does indeed exists outside of a customizable UI epic. So - based on this feedback, I’m going to remove language from the UI story and finalize it.
See you all tomorrow morning.
···
Kevin Cussen
Technology Manager
Village****Reach* ** Starting at the Last Mile*
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: 1.206.604.4209
www.villagereach.org
Connect on Facebook, Twitter** ** and our Blog
From: Josh Zamor
Sent: Monday, December 14, 2015 12:40
To: Kevin Cussen
Cc: Renee Orser; openlmis_product_committee@googlegroups.com; Rich Magnuson; Ben Leibert; Chongsun Ahn
Subject: Re: Customizable UI Definition
Hi Renee,
Okay, you’re going to get a bit of a mix of engineering and deployment process mixed together. As well as current state and thoughts on future state.
This is one of those cross-cutting concerns we’re thinking about in the re-architecture. Human language translatable messages start as keys such as “upload.record.error”. The keys and the original intention of a message should come from the code and the developer that created it for a specific intention - e.g. an error message, a label, etc
In reality the actual message used is often “translated” or changed for an implementation to target their program terminology. e.g. instead of using “Processing Period” which is an OpenLMIS term for a period of time that could be any number of months, our push-based systems tend to use “Month” as each processing period is simply a month long in the EPI programs. This is then actually translated into Portuguese, French, etc…
This is the default answer, however it needs to go a step further. The above describes the situation for the server-code, however it also describes the browser-based code as well as this code can really be seen as another application that is a client to the server. Moving into the re-architecture I don’t think these responsibilities will change, however I do think we will need to be more granular about what code component / module “owns” a message key. Code that owns a message key owns the intention behind that key, weather or not client code chooses to utilize it or “translate” it into it’s own intention. Human language translation and implementation level use is perhaps one of the last aspects in a deployment and so far I think that process, while tedious, is still working well when managed through a tool like Transifex.
Thoughts?
Hopefully this adds some clarity!
Best,
Josh
On Dec 8, 2015, at 5:24 PM, Kevin Cussen kevin.cussen@villagereach.org wrote:
Hi Renee,
Great question. I’m going to loop in Josh and see if this is the appropriate place to discuss translations or whether there is a better home for it elsewhere.
All - Please bring up any other discussion points by EOB tomorrow.
Cheers,
Kevin Cussen
Village****Reach* ** Starting at the Last Mile*
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: 1.206.604.4209
www.villagereach.org
Connect on Facebook, Twitter** ** and our Blog
From: Renee Orser rorser@thoughtworks.com
Sent: Monday, December 7, 2015 22:20
To: Kevin Cussen
Cc: openlmis_product_committee@googlegroups.com
Subject: Re: Customizable UI Definition
Hi Kevin,
I think this looks great. My only question is whether language would fall under this theme. Generally I associate “translatability” with code structure, rather than with what a user sees. But I could see us sliding it in here if we don’t have another theme that’s more appropriate.
Thanks,
Renee
On Tue, Dec 8, 2015 at 1:58 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:
Hi all,
Please find an updated description of the “Customizable UI” re-architecture Output (“RAO”) incorporating our discussions and your notes below. This is the definition I will begin to create user stories around with the VR dev team. Please comment by EOB, Wednesday, December 9th if you would like to make changes to this RAO.
The OpenLMIS user interface can be customized to specific implementations without forking the code base
Epic: Customizable UI
Description: Implementers need to be able to customize the UI without modifying the underlying APIs. The underlying APIs needs to remain stable so that countries can take advantage of new features of OpenLMIS without fear of breaking their implementation. OpenLMIS must offer a reference UI that implementers are at liberty to make simple modifications to through configuration screens. The reference UI must strive to be low bandwidth and device agnostic. The following UI elements need to be modifiable via configuration at the implementation level:
· Branding
· Language
· Labels
· Colors / Color Schemes
The preference is that these features are configurable by an administrator similar to configuration options in Drupal, Salesforce, or Wordpress. However, it is absolutely essential that if UI has to be changed at the code level that developers are able to modify these attributes without modifying the underlying core.
Wish List:
· Ability to configure UI based on user profile
Cheers,
Kevin Cussen
Village****Reach* ** Starting at the Last Mile*
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: 1.206.604.4209
www.villagereach.org
Connect on Facebook, Twitter** ** and our Blog
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Product Committee” group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis_product_committee+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis_product_committee@googlegroups.com.
To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis_product_committee/CY1PR02MB11197C89C1F702F117C6A384E3090%40CY1PR02MB1119.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.
–
Renee Orser
Solution Strategist
Email
rorser@thoughtworks.com
Telephone
+1-646-632-7926, +27-720841843
