Fwd: [WG: I18N & L10N] i18n BOF - stockholm

John Norman john at caret.cam.ac.uk
Thu May 7 06:17:32 UTC 2009


I know internationalisation/localisation isn't the same as  
personalisation, but it occurs to me that the problems are similar  
enough that people on this list might be able to make useful  
contributions to this discussion on the Sakai lists should you choose/ 
have time to do so...

Thanks
John

Begin forwarded message:

> From: Ray Davis <ray at media.berkeley.edu>
> Date: 6 May 2009 22:43:25 BST
> To: John Bush <john.bush at rsmart.com>
> Cc: i18n <i18n at collab.sakaiproject.org>, Sakai-Dev <sakai-dev at collab.sakaiproject.org 
> >
> Subject: Re: [WG: I18N & L10N] i18n BOF - stockholm
>
> 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.
>
> Best,
> Ray
>
> On 5/6/2009 1:19 PM, John Bush wrote:
>> well, this guy points out the same limitations I'm seeing:
>> http://www.javapractices.com/topic/TopicAction.do?Id=208
>>
>> and another thread on the topic:
>> http://forums.sun.com/thread.jspa?threadID=360447&tstart=45
>>
>> I'm usually the last guy to have the "not-built-here" mentality, but
>> for me resource bundles are very limiting.   Both spring and struts
>> developed alternatives because of these problems.
>>
>> John Bush
>> Development Manager
>> rSmart
>>
>> On May 6, 2009, at 11:18 AM, Aaron Zeckoski wrote:
>>
>>> I was hoping that resourceloader would head the other direction.  
>>> That
>>> is, simply supplying a locale from sakai which I could then use with
>>> my bundles. It seems like forcing systems to not use the standard
>>> process of loading i18n strings from properties files would head  
>>> even
>>> further away from the industry standard than we already are. For  
>>> Sakai
>>> 3 compatible thinking, I would suggest not going this route.
>>>
>>> -AZ
>>>
>>> On Wed, May 6, 2009 at 8:10 PM, John Bush <john.bush at rsmart.com>
>>> wrote:
>>>> This idea is probably somewhat dependent on SAK-12636, SAK-6886,  
>>>> but
>>>> has anyone ever thought of providing an alternative  
>>>> implementation of
>>>> ResourceLoader that would let you load the values from the  
>>>> database.
>>>> I get requests from clients everyday who want to change the
>>>> instructional text or other verbage.  I've often thought if the
>>>> bundles could be loaded out of the db, then you could create an  
>>>> admin
>>>> tool that would let you adjust the values for a locale at runtime.
>>>> Has an idea like this every been brought up before?  I think its
>>>> something we might start looking into.
>>>>
>>>> John Bush
>>>> Development Manager
>>>> rSmart
>>>>
>>>>
>>>>
>>>>
>>>> On May 6, 2009, at 9:39 AM, Beth Kirschner wrote:
>>>>
>>>>> Thanks Frank -- this is a good list of some of the more persistent
>>>>> problems of the existing sakai architecture. More issues can be
>>>>> found
>>>>> in confluence at http://confluence.sakaiproject.org/confluence/x/CkM
>>>>>
>>>>> With heavy heart, I wouldn't be able to attend the Boston Sakai
>>>>> conference this July, but I have asked Anthony Whyte of the Sakai
>>>>> Foundation to lead an Internationalization BOF. This would be a  
>>>>> good
>>>>> forum to continue the discussion on internationalization. I'll  
>>>>> post
>>>>> more details on this BOF as it becomes available.
>>>>>
>>>>> Thanks,
>>>>> - Beth
>>>>>
>>>>> On May 6, 2009, at 8:24 AM, Benneker, W.F.M. wrote:
>>>>>
>>>>>> At the 2nd european sakai conference we had a great BOF  
>>>>>> identiyfing
>>>>>> issues with i18n in Sakai 2.5/2.6. We also discussed how to  
>>>>>> getting
>>>>>> some workflow out there to settle some of the issues in Sakai 3.
>>>>>>
>>>>>> Attached is a photo with some of the issues disusses.
>>>>>>
>>>>>> Frank
>>>>>> University of Amsterdam
>>>>>> <06052009193.jpg>_______________________________________________
>>>>>> i18n mailing list
>>>>>> i18n at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to i18n-
>>>>>> unsubscribe at collab.sakaiproject.org with a subject of  
>>>>>> "unsubscribe"
>>>>> _______________________________________________
>>>>> i18n mailing list
>>>>> i18n at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>>>>
>>>>> TO UNSUBSCRIBE: send email to i18n-
>>>>> unsubscribe at collab.sakaiproject.org with a subject of  
>>>>> "unsubscribe"
>>>> _______________________________________________
>>>> i18n mailing list
>>>> i18n at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>>>
>>>> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org
>>>> with a subject of "unsubscribe"
>>>>
>>>
>>>
>>> -- 
>>> Aaron Zeckoski (aaronz at vt.edu)
>>> Senior Research Engineer - CARET - Cambridge University
>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>>
>> _______________________________________________
>> i18n mailing list
>> i18n at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>
>> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>
> _______________________________________________
> i18n mailing list
> i18n at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/i18n
>
> TO UNSUBSCRIBE: send email to i18n- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090507/87844642/attachment.html>


More information about the fluid-work mailing list