[WG: I18N & L10N] [Building Sakai] i18n BOF - stockholm

[Stephen Marquard]

Hi Ian,

That's great to hear (the "editable at runtime"). The best-case scenario for people doing customization to local deployments is to see something in a tool that you want changed, login as admin or whatever, find the UI string, edit it through the web UI and save and it updates immediately on all app servers, which sounds like it's achievable.

Second plus for developers would be if you could tweak the UI strings while running live for an app the same way, then do something that wrote them out to the default properties file or whatever to update the source code.

I'm sure if everyone added up the hours that have been spent tweaking properties files for 2.x through the edit / build / deploy / test cycle, it would come to a truly impressive number.

Cheers
Stephen

Stephen Marquard, Learning Technologies Co-ordinator
Centre for Educational Technology, University of Cape Town
http://www.cet.uct.ac.za
Email/IM/XMPP: stephen.marquard at uct.ac.za 
Phone: +27-21-650-5037 Cell: +27-83-500-5290 


>>> Ian Boston <ian at caret.cam.ac.uk> 2009/05/08 01:43 AM >>>

AFAIK, there will be almost no strings compiled into Sakai3/K2 code.
i18n and i10n files that are part of the UI will be stored on disk as  
files served by a http server (ie apache httpd) or in the JCR repo  
itself.
In addition the intention is to store all configuration settings other  
than instance settings in the jcr making them cluster wide and  
editable at runtime. Thats the intention.
Ian

On 7 May 2009, at 13:31, Stephen Marquard wrote:

> Another +1.
>
> I would have thought that this would be a prime example of a Sakai  
> 2.x limitation causing significant pain to adopting institutions  
> that Sakai 3 should be engineered to avoid or improve.
>
> Regards
> Stephen
>
> Stephen Marquard, Learning Technologies Co-ordinator
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za 
> Email/IM/XMPP: stephen.marquard at uct.ac.za 
> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>
>
>>>> "Adams, David" <da1 at vt.edu> 2009/05/07 02:26 PM >>>
>> I'm usually the second-to-last guy :) but I think it can be argued
> that
>> extremely customizable open source projects like Sakai would be  
>> better
>> off treating text strings as skinnable resources than as compiled
>> source code.
>
> +1
>
> Requiring a source code rebuild to update strings is very unfriendly  
> and
> hard to maintain. We've found that we can override some bundles by
> dropping an appropriately named file into tomcat/common/classes (is  
> that
> well-known?), but that's still troublesome, prone to error, and  
> requires
> systems staff intervention.
>
> Maybe it's the best of all bad solutions, but it seems like this is  
> the
> right time to examine the question while Sakai 3 is still being
> designed.
>
> -dave
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org 
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev 
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org 
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev 
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org 
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev 

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"