> Do you want to look at the date handlers
> and change the ones that you can in gramps32 and trunk?
I only commited changes on trunk.
True, files could be merged on branch as format_extras() and
get_new_year() are managed by the main Date Handler and date module.
Changes were the same. Only _Date_fi.py used an other method maybe
because before/after means a custom display wording location.
_Date_sv and _Date_nb do not use unicode on calendar names
Is it important ?
I do not have any syntax warning (gramps session) but I cannot test all
of them (need to have locale set).
Doug Blank a écrit :
> On Sat, Apr 10, 2010 at 3:16 AM, Jérôme <romjerome@...> wrote:
>> Maybe the less intrusive change (bug only) will be to only backport
>> modifications on localized Date Handlers (_Date_nl.diff)
> Ok, that sounds fine to me. Do you want to look at the date handlers
> and change the ones that you can in gramps32 and trunk? The trunk
> changes should work fine with those changes as well (and in fact they
> are needed anyway).
>> Code on trunk is more flexible  but no one has reported this problem
>> before (Gramps-3.1.x)
>> Only backport minor changes means no change on gen.lib.date, DateEdit, XML
>> import/export. Just March25, or Sept1 are still used : cannot use
>> "Month-Day" yet or translated newyear entries.
>>  http://en.wikipedia.org/wiki/New_Year#Other_new_year_celebrations
>> Doug Blank a écrit :
>>> Due to an issue in translating alternate newyears in dates, some
>>> changes needed to be made in trunk .
>>> Basically, Gramps' dates allow representing years that have a new
>>> year's day other than Jan. 1. For more information, see the section of
>>> the manual on dual-dated and alternate newyear-dated dates .
>>> Previously in Gramps, one needed to use a date format like:
>>> "Jun 6, 1742 (Mar25)"
>>> "Dec 25, 1738 (Julian,Jun1)"
>>> Now, one can replace the terms "Mar25" and "Jun1" with "3-25" and
>>> "6-1" respectively, or use any other "Month-Day" combination. In
>>> addition, spaces are now allowed after the comma after the calendar.
>>> There is an error in Gramps 3.2.0 that prevents non-English Gramps
>>> users from being able to edit these dates. Trunk now has fixes for
>>> parsing, displaying, and graphically editing these month-day alternate
>>> newyear date formats.
>>> If you would, please try running trunk (especially in other languages)
>>> and test alternate newyear dates in all parts of Gramps (import,
>>> export, reports, DB checks, editing, changing languages, etc).
>>> If everything looks good, we could apply these changes to 3.2.1.
>>>  - http://www.gramps-project.org/bugs/view.php?id=3756
>>>  -
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> Gramps-devel mailing list