[sakai2-tcc] Cross cutting concerns and prompt patching during a major release

[Steve Swinsburg]

FYI I've added a section to that page that covers i18n in Wicket:

http://confluence.sakaiproject.org/display/I18N/Best+Practices+for+Internationalized+Tools+in+Sakai#BestPracticesforInternationalizedToolsinSakai-Wicketbasedtools

cheers,
Steve


On 01/12/2010, at 1:58 AM, Jean-Francois Leveque wrote:

> There are already documented best practices in
> http://confluence.sakaiproject.org/display/I18N/Best+Practices+for+Internationalized+Tools+in+Sakai
> 
> They may not be complete (cover every dev use case) but it seems that, 
> most of the time, new developments aren't done using them and old code 
> is not reviewed by owners to account for them.
> 
> I will gladly help improve the best practices for more dev use case 
> coverage, but it seems very few devs mind because they haven't asked any 
> question about this documentation for cases not covered.
> 
> Maybe we should ask devs to document how their code is internationalized 
> first instead of having to find ourselves and be disappointed. Could 
> this be requested for new releases?
> 
> J-F
> 
> David Haines a écrit :
>> One way to sidestep some of these issues is to have clear best practices 
>> for cross cutting concerns.  If an issue does occur a lot in different 
>> context there very likely is a standard approach that works in Sakai. 
>> If that is well documented then developers will know where to find a 
>> good solution.  Increasing this kind of consistency reduces everybody's 
>> work load in the long run by avoiding churn when things need to updates 
>> / fixes / enhancements. 
>> 
>> Is there a clearly documented set of best practices for 
>> internationalization?  If not is this an area that could have clear best 
>> practices?
>> 
>> - Dave
>> 
>> David Haines
>> CTools Developer
>> Digital Media Commons
>> University of Michigan 
>> dlhaines at umich.edu <mailto:dlhaines at umich.edu>
>> 
>> 
>> 
>> 
>> On Nov 30, 2010, at 8:54 AM, DAVID ROLDAN MARTINEZ wrote:
>> 
>>> I was not talking about changes in properties files. I can manage them 
>>> by myself and make the commit directly without asking permission 
>>> because they are low risk changes.
>>> 
>>> I was talking about functionality bugs. Tools that don't work at all 
>>> if you change the language and, for example, shows the content in 
>>> English because they are not able to change dynamically language to 
>>> adapt to user preferred language. Will you put in production a tool 
>>> that shows everything in Chinese to non-Chinese speaking users? I'm 
>>> sure you won't, won't you? I'm talking about tools that use conditions 
>>> based in hardcoded English values at checkboxes o radiobuttons and 
>>> that, when you change the languages, don't respond and seem to do nothing.
>>> 
>>> I'm not talking about providing the tasks and leave the tool/project 
>>> leader alone. I'm talking about helping him/her to test it (once 
>>> again, because we don't upload a patch if it hasn't been property 
>>> tested) and make the commit to save him/her time. I'm talking about 
>>> improving Sakai existing features that are objectively working bad not 
>>> about adding new features that you can find useful or you can't.
>>> 
>>> I'm not offering only a list of problems but also solutions to those 
>>> problems. Why not to take it in a more agile way, above all if the 
>>> tool/project leader is unresponsive?
>>> 
>>> What we should state clearly is what we want Sakai to be. Do we want 
>>> Sakai to be spread all around the world? If yes, we must fix i18n 
>>> issues first. Do we want Sakai to be used by disabled people? If yes, 
>>> we must fix accessibility issue first. Do we have a strategic approach 
>>> or roadmap about which are the objectives that Sakai want to reach? If 
>>> don't, probably, we must invest time into this before to continue 
>>> discussing about how patches should be managed. In order to deploy 
>>> tactic plans (for example, guidelines to make patch management more 
>>> efficiently and effectively), we must have better defined the 
>>> strategic plan.
>>> 
>>> -----Mensaje original-----
>>> De: csev [mailto:csev at umich.edu]
>>> Enviado el: martes, 30 de noviembre de 2010 14:37
>>> Para: sakai2-tcc at collab.sakaiproject.org 
>>> <mailto:sakai2-tcc at collab.sakaiproject.org> Committee
>>> CC: DAVID ROLDAN MARTINEZ; Megan May
>>> Asunto: Re: [sakai2-tcc] Cross cutting concerns and prompt patching 
>>> during a major release
>>> 
>>> 
>>> On Nov 30, 2010, at 7:59 AM, May, Megan Marie wrote:
>>> 
>>>> My two cents - when leads are unresponsive to patches that is when 
>>>> the SF staff members should be brought in.    I'm also going to throw 
>>>> in that getting patches reviewed/committed isn't just an issue for 
>>>> i18n.   
>>> 
>>> 
>>> I was thinking a similar thing - this probably is not about properties 
>>> file changes - which I think moves in pretty quickly with Beth making 
>>> sure things move reasonably deterministically.    If there is some 
>>> sticking point about properties changes - then we should understand 
>>> what those are.   If project leads are resisting properties changes or 
>>> making them wait a long time - that is not good at all.
>>> 
>>> I am guessing that this is more about functionality changes to improve 
>>> the ability to internationalize something - this is not something that 
>>> Beth fast-tracks and requires a bit of project team involvement. 
>>>  Historically, these code tweaks are not always as trivial as they 
>>> sound on the surface and I hesitate creating a process that pushes 
>>> them in when a timer expires.
>>> 
>>> In a sense, we are better off with a slightly broken Russian 
>>> translation than no translation - but we are not better off with 
>>> broken or inconsistent functionality.
>>> 
>>> I am mindful of the effort that made button text translatable and the 
>>> number of hacks that 'solved the problem for now' versus the 
>>> longer-term careful work that went into fixing it properly.
>>> 
>>> We need to be careful not to conflate "properties changes" which have 
>>> historically been given special privilege and fast-tracked - with 
>>> other forms of internationalization-related code changes that really 
>>> fall into the same category as other code changes and need to be 
>>> worked into a project effort and resourced.
>>> 
>>>> My comments were solely in response to Chucks suggestion to changing 
>>>> the JIRA workflow and trying to better understand the differences in 
>>>> the different suggestions.  It's a dirty secret but I love 
>>>> reengineering processes :-) The first step  in that is truly 
>>>> understanding what people want to accomplish.
>>> 
>>> I have lost track of the multiple suggestions for how we tweak the UI. 
>>> I want an indication that anyone can set that says a JIRA is 
>>> "trunk-ready" much like we already indicate "ready to merge" in the 
>>> various branches.  Some else said we need a "patch attached checkbox" 
>>> - as a project lead I find a mere checkbox that a patch is attached as 
>>> useless.  When I have a few days few to work on portal after a month 
>>> where local priorities took me away, I want to be able to quickly scan 
>>> and find the low hanging fruit so I can make the best progress and get 
>>> the most work done in my limited time.  Without the trunk ready flag, 
>>> the job of scanning my "queue" is just harder - so I will get less 
>>> done and likely miss some low-hanging patch fruit.
>>> 
>>> I lost track of where the conversation was going - I made my 
>>> suggestion with my project lead hat on - no one agreed - counter 
>>> proposals were put out that I liked less - so I kind of figured I 
>>> would drop the conversation and let the collective figure it out. :)
>>> 
>>> /Chuck
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc