[be] [task #9403] Chorus support

[Teus Benschop]

URL:
  <http://savannah.nongnu.org/task/?9403>

                 Summary: Chorus support
                 Project: Bibledit
            Submitted by: teus
            Submitted on: Wed 20 May 2009 05:10:54 PM CAT
                  Status: None
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

There is a project underway called 'Chorus' that is effectively a nice UI
over mercurial (or some other distributed version control system). It provides
an API so that programs can easily support DVCS, and merge - particularly
delaying the conflict resolution to a more convenient time.

For a repository we are working on using something like redmine
(http://www.redmine.org) to manage a web based repository.

Further details on chorus can be found here:

http://projects.palaso.org/projects/show/chorus 

If Bibledit were to support Chorus, that might be helpful.

    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sun 18 Jul 2004 12:51:40 PM CATBy: Richard Frith-Macdonald <CaS>
No feedback received after a month ... so I'm closing this bug.

-------------------------------------------------------
Date: Mon 21 Jun 2004 03:35:24 PM CATBy: Richard Frith-Macdonald <CaS>
I have updated the NSCalendarDate code to understand '%r' when producng
descriptions ... that should avoid problems when something sets the format for
a date to contain a '%r'.

It does not address any problem with NSLanguages of course.  To look into
that I need more information about what the exact issue is and how to
reproduce it. I'm not sure that there is any requirement that NSLanguages
*should* be set, and as far as I can see, the +userLanguages method should
work reasonably whether NSLanguages is set or not.


-------------------------------------------------------
Date: Mon 21 Jun 2004 09:58:24 AM CATBy: Richard Frith-Macdonald <CaS>
Please coud you clarify the nature of the bug.

Are you saying that the NSLanguages user default is not being set in some
circumstances?  If so, are you able to provide instructions to reproduce
this?

The '%r' you are seeing does not appear to be a 'legal' format.  If you look
at the Cocoa documentation for 'descriptionWithCalendarFormat:'  it refers you
to a short section on 'Setting the Format for Dates', which in turn refers you
to 'Date Formatters', which is described as 'a complete description of the
syntax of date format strings', ad this does not include '%r'

However, GNUstep has an extension to map '%r' to be '%I:%M:%S %p' at the
point where a date is created... but this mapping is independant of the
NSLanguages default.
I guess Cocoa might have a similar undocumented feature.  (or even documented
in some other conflicting part of the docmentation).

However, there is a question of where the '%r' is coming from...
Since GNUstep maps it when a date is created, the only thing I cas think is
that it's in a format set into a date using the setFormat: method.
Perhaps it comes from GMUmail ... in which case there would be a bug there,
but I think it's at least as likely that GNUstep is picking it up from the
locale information provided by the operating system.  If this is the case,
then the bug is in mapping the O/S locale information to OpenStep/Cocoa locale
information.







    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?9403>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/