[cle-release-team] CLE 2.9.2 update: merge work complete
Anthony Whyte
arwhyte at umich.edu
Fri Apr 19 12:34:55 PDT 2013
Agreed. Both trunk and 2.9.x changes have been reverted and noted in SAK-23435. Aaron tested trunk; I tested 2.9.x locally.
I leave it to the advocates for change to gather further opinions on the i18n and dev lists. I do think we can sort this out to everyone's satisfaction.
However, in my opinion such a discussion should not block further progress on 2.9.2 or the 2.9.2 release itself since the ticket is neither a blocker nor critical (it may not even constitute a bug).
Let's get an RC tag out. We are now a few days behind schedule.
Now back to my vacation day,
Cheers,
Anthony
On Apr 19, 2013, at 1:05 PM, Beth Kirschner wrote:
> I think this was a well intentioned change that needs more thought - I vote for backing out SAK-23435 for now. We should poll the I18N list for their opinions, clearly stating what the use cases are (e.g. Site Preferences, Personal Preferences, etc.), along with the pro's and con's of both sides.
>
> I think Wikipedia has a different audience than the users of a particular Sakai instance at a particular institution in a particular locale. I can see arguments for both sides, so given that there is no clear right path, I think the best course of action is to back out the change and gather some more opinions. If lacking a clear consensus, perhaps the right choice would be to make this a configurable option, with the pre-SAK-23435 behavior as default.
>
> - Beth
>
> On Apr 19, 2013, at 11:22 AM, Anthony Whyte <arwhyte at umich.edu> wrote:
>
>>>
>>> I'm asking this for the community which doesn't use English.
>>
>>
>> What does English vs non-English speakers have to do with this discussion? As you point out in the ticket, if the default locale is set to Chinese, the drop down options are spelled out using Chinese characters (and sorted accordingly).
>>
>> Anth
>>
>> On Apr 19, 2013, at 11:13 AM, Jean-Francois Leveque wrote:
>>
>>> SAK-23435 is the requirement I'm referring to.
>>>
>>> Please take time to think about it and why wikipedia does it the way we're asking.
>>>
>>> If you still disagree, please ask for more input or state your decision on i18n at collab.sakaiproject.org.
>>>
>>> I'm asking this for the community which doesn't use English.
>>>
>>> Displaying the locale in its own locale does not impose locale-independent naming, it provides locale-dependent display of its own locale.
>>>
>>> Do we expect users to be able to spell their languages and countries in all other languages?
>>>
>>> Cheers,
>>>
>>> J-F
>>>
>>> On 19/04/2013 17:05, Anthony Whyte wrote:
>>>> At first I was inclined to agree with JFL: display each language option in the drop down using the script and common name understood by each native speaker. So the Russian option is displayed in Cyrillic script, Hungarian is labeled Magyar and so on, irrespective of the default locale controlling text in the rest of the interface.
>>>>
>>>> On reflection, this appears wrong to me and represents an exception to the notion that interface elements such as drop down options should adhere to the linguistic, cultural and technical conventions and standards of a chosen locale. The approach taken in https://jira.sakaiproject.org/browse/SAK-23435 appears to violate this principle as it imposes a locale-independent naming and sorting approach which renders certain drop down options potentially incomprehensible to certain users, irrespective of their preferred locale.
>>>>
>>>> I'm with Aaron, we should revert this change (for a quick review of what's changed compare Nightly2 2.8.x and 2.9.x).
>>>>
>>>> JFL--what requirement are you referring to below?
>>>>
>>>> Cheers,
>>>>
>>>> Anth
>>>>
>>>>
>>>>
>>>> On Apr 19, 2013, at 10:12 AM, Jean-Francois Leveque wrote:
>>>>
>>>>> It won't pass testing on i18n user locale preferences requirement. ;-)
>>>>>
>>>>> On 19/04/2013 16:11, Neal Caidin wrote:
>>>>>> So if rc01 passes testing, we would have an rc02 anyway?
>>>>>>
>>>>>>
>>>>>> On Apr 19, 2013, at 9:57 AM, Jean-Francois Leveque<jean-francois.leveque at upmc.fr> wrote:
>>>>>>
>>>>>>> We could decide to have a rc02 if we can't wait for rc01.
>>>>>>>
>>>>>>> On 19/04/2013 15:55, Neal Caidin wrote:
>>>>>>>>> I'm not asking for postponing 2.9.2-rc01, but I think we really need it in the 2.9.2 official release.
>>>>>>>>
>>>>>>>> The point of the rc01 is that if it passes testing then it becomes the official release. The decision needs to be made whether to back out the change and proceed with rc01, or fix it for 2.9.2, which means delaying rc01 until that is figured out. Saying to not fix it for rc01, but do fix it for the 2.9.2 official release doesn't work. (Am I wrong? This is what makes sense to me.)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Neal
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 19, 2013, at 9:38 AM, Jean-Francois Leveque<jean-francois.leveque at upmc.fr> wrote:
>>>>>>>>
>>>>>>>>> I think the locale should be displayed in its own language.
>>>>>>>>>
>>>>>>>>> Look at how the languages are displayed on the left in http://en.wikipedia.org/wiki/Main_Page for example.
>>>>>>>>>
>>>>>>>>> If you don't know how the locale is named in its own language, you should not choose this language in the preferences, AFAICT.
>>>>>>>>>
>>>>>>>>> Please don't forget I'm doing this for others. If the majority of the CLE team really want what Aaron wants, please make your statement on i18n at collab.sakaiproject.org. Otherwise, I expect to get this fix in 2.9 ASAP.
>>>>>>>>>
>>>>>>>>> I'm not asking for postponing 2.9.2-rc01, but I think we really need it in the 2.9.2 official release.
>>>>>>>>>
>>>>>>>>> J-F
>>>>>>>>>
>>>>>>>>> On 19/04/2013 15:25, Aaron Zeckoski wrote:
>>>>>>>>>> This is because the actual name of the "Nederlands" language is Dutch
>>>>>>>>>> (to an english speaker) and D is before E. I actually think this
>>>>>>>>>> change from
>>>>>>>>>> https://jira.sakaiproject.org/browse/SAK-23435
>>>>>>>>>> is wrong the more I think about it. The language should be displayed
>>>>>>>>>> to the user and sorted by the language name they would understand and
>>>>>>>>>> not by the name of the language in a language they probably cannot
>>>>>>>>>> read or might not know.
>>>>>>>>>>
>>>>>>>>>> A solution might be show the language as "Dutch (Netherlands) -
>>>>>>>>>> Nederlands (Nederland)" or something like that. There is plenty of
>>>>>>>>>> room in the UI for it.
>>>>>>>>>>
>>>>>>>>>> I think all the changes for this ticket need to be reverted and
>>>>>>>>>> discussed further. They definitely should not be merged to 2.9.
>>>>>>>>>>
>>>>>>>>>> -AZ
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 19, 2013 at 8:47 AM, Jean-Francois Leveque
>>>>>>>>>> <jean-francois.leveque at upmc.fr> wrote:
>>>>>>>>>>> As far as I can tell, the values are not in a alpha case-insensitive which
>>>>>>>>>>> is the expected order, or even case-sensitive order, AFAICT.
>>>>>>>>>>>
>>>>>>>>>>> français is before Deutsch and Nederlands is before English.
>>>>>>>>>>>
>>>>>>>>>>> Each locale is now displayed in the language for that locale, but the
>>>>>>>>>>> sorting should be on displayed, not other values such as the locale name in
>>>>>>>>>>> English.
>>>>>>>>>>>
>>>>>>>>>>> Please check the LocaleComparator and provide code that does the work.
>>>>>>>>>>>
>>>>>>>>>>> J-F
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 19/04/2013 14:01, Aaron Zeckoski wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It looks fine to me as is (appearing in alpha order by language) but I
>>>>>>>>>>>> guess there is some concern about the ordering of the languages or
>>>>>>>>>>>> something I am not getting.
>>>>>>>>>>>> -AZ
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Apr 19, 2013 at 7:46 AM, Neal Caidin
>>>>>>>>>>>> <nealcaidin at sakaifoundation.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> What are the options?
>>>>>>>>>>>>>
>>>>>>>>>>>>> * fix and re-merge before cutting 2.9.2-rc01
>>>>>>>>>>>>> * proceed with cutting rc01 with this as a known issue
>>>>>>>>>>>>> * back this change out of 2.9.x to revert the regression, then proceed
>>>>>>>>>>>>> with rc01
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I presume that this is currently the only issue holding up rc01?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Neal
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Apr 19, 2013, at 5:04 AM, Anthony Whyte<arwhyte at umich.edu> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm on the road today (day off) but I'll check back later this morning
>>>>>>>>>>>>>> and see if there is any further work on the ticket.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anth
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Apr 19, 2013, at 4:30 AM, Jean-Francois Leveque wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Changes in https://jira.sakaiproject.org/browse/SAK-23435 broke the
>>>>>>>>>>>>>>> locales order in the user preferences.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I had to reopen this issue. I also had to close it before reopening
>>>>>>>>>>>>>>> because of the workflow. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> J-F
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18/04/2013 21:48, Anthony Whyte wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sam, Aaron and I just completed 2.9.x merge work. The 2.9.x merge
>>>>>>>>>>>>>>>> backlog now stands at 2 tickets, both of which are being punted to the 2.9.3
>>>>>>>>>>>>>>>> release. [1] I think its time to consider cutting 2.9.0-rc01 tag.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I also recommend that from this moment until 2.9.x is released, we
>>>>>>>>>>>>>>>> limit branch merge work to release blockers and regressions discovered
>>>>>>>>>>>>>>>> during final testing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've started a local build of 2.9.x-all against an empty .m2 repo. If
>>>>>>>>>>>>>>>> I hit a build failure you'll be the first to know.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] https://jira.sakaiproject.org/browse/SAK-22798
>>>>>>>>>>>>>>>> major, accessibility; merge conflicts, Gonzalo Silverio and Joe
>>>>>>>>>>>>>>>> Humbert concur that we can punt on this
>>>>>>>>>>>>>>>> https://jira.sakaiproject.org/browse/SAK-22521
>>>>>>>>>>>>>>>> major, neoPortal sites drawer issue, no trunk commit revision
>>>>>>>>>>>>>>>> provided despite repeated requests, so punt
>>
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
More information about the cle-release-team
mailing list