proposed patch (date-format report option)

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Josip
28.2.2017. u 0:17, Paul Franklin je napisao/la:

> On 2/27/17, Josip <[hidden email]> wrote:
>
>> I am not English speaker but new tooltip:
>> "The format (and language) dates will be shown in (with examples)"
>> looks quite confusing for me.
>
> Maybe removing the parentheses?
>
>  "The format and language for dates, with examples"
>

That is more understandable, at least for me

> I happily solicit suggestions from anybody else.
> If we gets lots of them we can vote.  8-)
>
>> Lots of date format names/descriptions have parentheses or round
>> brackets in them also so putting example in it not distinguish him
>> enough. Can one of them use bold font.
>
> I'll look into it, but what about Japanese, Chinese, Arabic,
> Hebrew?  Can one bold them?  Certainly I don't know.
>

I think any font can be made bold

>> I also notice that for me in Windows this languages does' not work
>> (format names are in chosen language but example in my locale):
>> Albanian, Esperanto, Turkish, Vietnamese
>
> Yes, if you do a search for "January" in the corresponding
> xx.po file you'll see that those languages do not have the
> month names translated.  They fail in linux (and Mac) also.
>
> I suppose Jerome or I could run that module Vassilii
> set up to run stand-alone, and create the date strings,
> then merge them in, but evidently that hasn't happened.
>
> "Keep those cards and letters coming."  8-)
>

Just to mention that Gramps in Windows can't be started with neither of
Esperanto or Vietnamese. Jet reports in those languages works except dates.

--
Josip

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 2/27/17, Josip <[hidden email]> wrote:
> Just to mention that Gramps in Windows can't be started with neither of
> Esperanto or Vietnamese. Jet reports in those languages works except dates.

Thank you for reminding me:

Eventually, you or some other Windows developer should
see what happens when a user tries to output a report in
a language which the user didn't install.

I don't know if that is detected, and if so where and how,
and if so what should be done.

(Given the users who have posted, complaining, then
found out they'd skipped that Windows installation stage,
maybe some dialog should pop up, or something, when
they try to run gramps in a non-installed language?  Just
a thought.)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
In reply to this post by Josip
>>> Lots of date format names/descriptions have parentheses or round
>>> brackets in them also so putting example in it not distinguish him
>>> enough. Can one of them use bold font.
>>
>> I'll look into it, but what about Japanese, Chinese, Arabic,
>> Hebrew?  Can one bold them?  Certainly I don't know.
>>
>
> I think any font can be made bold

Can anybody point me at an example of an EnumeratedList
item which has bold text, which I can then try to crib from?

Thanks.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 2/27/17, Paul Franklin <[hidden email]> wrote:

>>>> Lots of date format names/descriptions have parentheses or round
>>>> brackets in them also so putting example in it not distinguish him
>>>> enough. Can one of them use bold font.
>>>
>>> I'll look into it, but what about Japanese, Chinese, Arabic,
>>> Hebrew?  Can one bold them?  Certainly I don't know.
>>>
>>
>> I think any font can be made bold
>
> Can anybody point me at an example of an EnumeratedList
> item which has bold text, which I can then try to crib from?
>
> Thanks.
>

Or any other bold Gtk.ComboBoxText item?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

John Ralls-2
In reply to this post by Paul Franklin-5

> On Feb 27, 2017, at 12:49 PM, Paul Franklin <[hidden email]> wrote:
>
> Hi John,
>
> One of the problems I noticed when I was testing my new
> patch has to do with one of the date format choices.
>
> The second choice typically, right after the default ISO
> one, is a "numerical" one, which shows dates like 12/25/2016
> for people in the United States and dates like 25/12/2016
> for people in England.
>
> You might remember that about a year ago an Australian user
> filed a bug report complaining that he could only enter
> dates in the American (month-first) format, whereas he
> wanted to be able to enter them in the typical (day-first)
> format he was used to. [1]
>
> You might also remember that you and I discussed possible
> solutions to the problem.  I proposed moving the "tformat"
> definition from gen/datehandler/_grampslocale.py into the
> GrampsLocale class.  But you changed GrampsLocale so that
> the default locale for all English-locale users was en_GB,
> unless they were in the United States in which case they
> kept the en_US locale (and thus its date format).
>
> The problem is that _grampslocale.py's "tformat" definition
> is derived from an import of "locale" -- which of course is
> always the user's real locale, the UI one. [2]
>
> So I believe that is the tformat which is used to determine
> the "numerical" date format.  That is, no matter what locale
> I have selected using my proposed option, the "numerical"
> date formats are always shown in my (en_US) format, month
> first.  Even if the format choice says otherwise.  So for
> users like me, here, that "numerical" format will likely
> never be correct, for other languages.
>
> I admit it's less of a problem for people in other English
> locales, since they will only hit a problem if they output a
> report in American English.
>
> But what about people whose natural numerical format starts
> with a year?  Then if they output a report in another
> language the numerical dates will look pretty wrong.  And if
> an English speaker generates a report in their locale our
> (incorrect) numerical format will be used also.
>
> So my guess is that the problem would be solved if the
> tformat definition (and its backup definition, I guess) were
> moved out of gen/datehandler/_grampslocale.py and into
> GrampsLocale.  Although I haven't tried to test that idea.
>
> What do you think?

Paul,

Good thought. Yes, it should apply to secondary locales as well. If you see an easy way to do it by moving the code from utils/grampslocale.py to datehandlers/_grampslocale.py, give it a try.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

John Ralls-2
In reply to this post by Paul Franklin-5

On Feb 27, 2017, at 7:52 PM, Paul Franklin <[hidden email]> wrote:

On 2/27/17, Paul Franklin <[hidden email]> wrote:
Lots of date format names/descriptions have parentheses or round
brackets in them also so putting example in it not distinguish him
enough. Can one of them use bold font.

I'll look into it, but what about Japanese, Chinese, Arabic,
Hebrew?  Can one bold them?  Certainly I don't know.


I think any font can be made bold

Can anybody point me at an example of an EnumeratedList
item which has bold text, which I can then try to crib from?

Thanks.


Or any other bold Gtk.ComboBoxText item?


Paul,

I don't think you can do it from a GtkComboBoxText. I think you'll have to change to a GtkComboBox and set the use-markup property on the GtkCellRenderer and then pass in Pango markup in your string.

Regards,
John Ralls



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 2/27/17, John Ralls <[hidden email]> wrote:

>> Or any other bold Gtk.ComboBoxText item?

> I don't think you can do it from a GtkComboBoxText. I think you'll have to
> change to a GtkComboBox and set the use-markup property on the
> GtkCellRenderer and then pass in Pango markup in your string.

Thanks, John.  That's good to know.

It gives me another approach to try.

I'd already cribbed the code from another bold
string and tried it, but the whole markup appeared
in the combo box (with the example date in the
middle of it) so I figured it wasn't going to work.

But that ComboBoxText is the heart of the gramps
GuiEnumeratedListOption implementation.  If I do
get it to work, by changing it as you suggest, will there
be any chance of any adverse effects with all the other
uses of that class, elsewhere in gramps?  Of course
I don't want to risk anything bad happening, due to
my ignorance.

Thanks.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

John Ralls-2

> On Feb 27, 2017, at 9:40 PM, Paul Franklin <[hidden email]> wrote:
>
> On 2/27/17, John Ralls <[hidden email]> wrote:
>
>>> Or any other bold Gtk.ComboBoxText item?
>
>> I don't think you can do it from a GtkComboBoxText. I think you'll have to
>> change to a GtkComboBox and set the use-markup property on the
>> GtkCellRenderer and then pass in Pango markup in your string.
>
> Thanks, John.  That's good to know.
>
> It gives me another approach to try.
>
> I'd already cribbed the code from another bold
> string and tried it, but the whole markup appeared
> in the combo box (with the example date in the
> middle of it) so I figured it wasn't going to work.
>
> But that ComboBoxText is the heart of the gramps
> GuiEnumeratedListOption implementation.  If I do
> get it to work, by changing it as you suggest, will there
> be any chance of any adverse effects with all the other
> uses of that class, elsewhere in gramps?  Of course
> I don't want to risk anything bad happening, due to
> my ignorance.

Paul,

Depends on how well you can hide the change in the underlying implementation. Ideally you can change the internals without changing the existing class interface so that the existing users don't need changes. GtkComboBoxText is just a simplification wrapper around GtkComboBox and all of the bits that go into it, so hiding the more complex implementation is obviously possible, but it might be more work than you want to do.

Regards,
John Ralls
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 2/27/17, John Ralls <[hidden email]> wrote:
> Depends on how well you can hide the change in the underlying
> implementation. Ideally you can change the internals without changing the
> existing class interface so that the existing users don't need changes.
> GtkComboBoxText is just a simplification wrapper around GtkComboBox and all
> of the bits that go into it, so hiding the more complex implementation is
> obviously possible, but it might be more work than you want to do.

The more I think about this, after looking around for other
Gtk.ComboBox() uses and especially after looking at the
GuiEnumeratedListOption class, where it would need to
be put (unless I invented a whole new class), the less I
am convinced it is possible, to turn anything in the option
choice string into bold text.

There are too many levels of abstraction involved, and for
very good reasons.  The main one (I think) being that reports
have to work on the command line also.  (So just for fun I
attach a transcript file, showing some examples of the use
of this new option.  It's just a "text" file, but I ran it in an emacs
shell, which I have discovered is a convenient way (for me)
to get fonts my normal xterm doesn't have, like Arabic.  Then
I cut-and-pasted into this file, so it's anybody's guess
whether your text reader will cope.)

But the point is that this option has to work in the CLI, which
means (I think) that its option choices have to be available
that way too.  Well, they are of course, since they are just
numbers.  But that means the option choice /descriptions/
have to be defined in a generic (low-level) fashion, without
any Pango markup.

So bolding anything needs to be done later, outside the option
definition (which I am doing here, putting it into stdoptions.py).

But I can't think of any way that can be done, using the existing
abstractions.  But without ever trying it, I can imagine it might
be possible to define a new option type, a subclass of the parent
EnumeratedListOption (the way a FilterOption is a subclass of
it), maybe.  Then I could imagine two flavors of a "description" --
one bold, one normal -- where the bold one was treated as
normal text for a CLI output but bolded for the GUI.

But that is more than I want to try doing right now, and is really
orthogonal to my self-feature-request of adding a date format
to reports.  Adding bold-section option choices can be thought
of as another feature request, independent of this one.

Accordingly, I attach the latest version of my proposed option,
with nothing done to bold any text, just shorten the tooltip.  I
hope it will be the final version but of course that depends on
whatever comments all the rest of you make, if any.

Thanks to all, for your help and suggestions.  I'm grateful.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

transcript (5K) Download Attachment
20170228A=report-dates.trunk.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Josip
28.2.2017. u 20:13, Paul Franklin je napisao/la:
> The more I think about this, after looking around for other
> Gtk.ComboBox() uses and especially after looking at the
> GuiEnumeratedListOption class, where it would need to
> be put (unless I invented a whole new class), the less I
> am convinced it is possible, to turn anything in the option
> choice string into bold text.

Just put translated example in label of his own, without all this
complication :-)

--
Josip

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 2/28/17, Josip <[hidden email]> wrote:

> 28.2.2017. u 20:13, Paul Franklin je napisao/la:
>> The more I think about this, after looking around for other
>> Gtk.ComboBox() uses and especially after looking at the
>> GuiEnumeratedListOption class, where it would need to
>> be put (unless I invented a whole new class), the less I
>> am convinced it is possible, to turn anything in the option
>> choice string into bold text.
>
> Just put translated example in label of his own, without all this
> complication :-)

I like seeing the array of all of them, with all their dates!
8-)

But I think it's a good UI choice, since it makes it really
obvious what is happening.  Besides, your suggestion
doesn't have any CLI equivalent.  8-)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

jerome
In reply to this post by Paul Franklin-5

 > > I also notice that for me in Windows this
 languages does' not work
 > > (format
 names are in chosen language but example in my locale):
 > > Albanian, Esperanto, Turkish,
 Vietnamese
 
>  Yes, if you do a
 search for "January" in the corresponding
> xx.po file you'll see that those languages
 do not have the
> month names translated. 
 They fail in linux (and Mac) also.

This might be a little bit difficult to run the 'migration' script if locales are not installed (supported) by the
system (e.g., linux).

One solution for bug report #4089 was to run something like:

>>> locale.setlocale(locale.LC_ALL,'fi_FI.utf8')
'fi_FI.utf8'
>>> locale.nl_langinfo(locale.MON_1)
'tammikuu'
>>> locale.nl_langinfo(locale.MON_2)
'helmikuu'
>>> locale.nl_langinfo(locale.MON_3)
'maaliskuu'
>>> locale.nl_langinfo(locale.MON_4)
'huhtikuu'
>>> locale.nl_langinfo(locale.MON_5)
'toukokuu'
>>> locale.nl_langinfo(locale.MON_6)
'kes\xc3\xa4kuu'
>>> locale.nl_langinfo(locale.MON_7)
'hein\xc3\xa4kuu'
>>> locale.nl_langinfo(locale.MON_8)
'elokuu'
>>> locale.nl_langinfo(locale.MON_9)
'syyskuu'
>>> locale.nl_langinfo(locale.MON_10)
'lokakuu'
>>> locale.nl_langinfo(locale.MON_11)
'marraskuu'
>>> locale.nl_langinfo(locale.MON_12)
'joulukuu'

Also, I suppose there is a "inflexion" issue on
these key entries?


Jérôme

 
 ------------------------------------------------------------------------------
 Check out the vibrant tech community on one of
 the world's most
 engaging tech sites,
 SlashDot.org! http://sdm.link/slashdot
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
In reply to this post by Paul Franklin-5
On 2/26/17, Paul Franklin <[hidden email]> wrote:

>>> Maybe I could put an example date on the choice line,
>>> in parentheses?  I'll see.
>
> That is my current approach.  There seems to be room.

> I will check whether the length of the longest formats I
> can find still allow room for example dates.  (Lithuanian
> comes to mind, one of them.)  Good point.

I forgot that Gtk will expand the whole dialog to make room
for the longest string, so there will always be room.

(I noticed this when I was trying the Pango markup, which
didn't work but it was all shown, in the much-wider dialog.)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
In reply to this post by Josip
On 2/27/17, Josip <[hidden email]> wrote:
> I also notice that for me in Windows this languages does' not work
> (format names are in chosen language but example in my locale):
> Albanian, Esperanto, Turkish, Vietnamese

There are now month names in all four of our po files
(and abbreviations and weekday names).

Whether you can run them on Windows, I don't know.

I would guess that maybe you can run in Esperanto
on Arch though, so if you know Esperanto you might
load datestrings.gramps and see if the dates look
right to you.  (No Esperanto locale for me.)  When I
looked in eo.po I saw that some of the words which
modify dates ("before" and "after" for instance) didn't
seem to have any spaces after them.  But of course
maybe that's the way Esperanto dates are (since I
don't know the language).

HTH.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Josip
3.3.2017. u 9:28, Paul Franklin je napisao/la:

> On 2/27/17, Josip <[hidden email]> wrote:
>> I also notice that for me in Windows this languages does' not work
>> (format names are in chosen language but example in my locale):
>> Albanian, Esperanto, Turkish, Vietnamese
>
> There are now month names in all four of our po files
> (and abbreviations and weekday names).
>
> Whether you can run them on Windows, I don't know.
>
> I would guess that maybe you can run in Esperanto
> on Arch though, so if you know Esperanto you might
> load datestrings.gramps and see if the dates look
> right to you.  (No Esperanto locale for me.)  When I
> looked in eo.po I saw that some of the words which
> modify dates ("before" and "after" for instance) didn't
> seem to have any spaces after them.  But of course
> maybe that's the way Esperanto dates are (since I
> don't know the language).
>
> HTH.
>

Environment variable LANGUAGE="eo" must be used in Windows to run Gramps
in Esperanto. Dates is displayed in Esperanto.

In report options example date still not work for Esperanto

BTW
Maybe we can have two option for translated dates: "gramps way" and ICU
way". PyICU is optional dependencies for Gramps (included in Windows AIO
bundle)
For example different format of current day in Esperanto:

$ python3
Python 3.5.2 (default, Nov 12 2016, 17:21:29)  [GCC 6.2.0 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import icu
 >>> for i in (icu.DateFormat.FULL, icu.DateFormat.LONG,
icu.DateFormat.MEDIUM, icu.DateFormat.SHORT):
...   df= icu.DateFormat.createDateInstance(i, icu.Locale('eo'))
...   print (df.format(icu.Calendar.getNow()))
...
vendredo, 3-a de marto 2017
2017-marto-03
2017-mar-03
17-03-03
 >>>

--
Josip

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
In reply to this post by Paul Franklin-5
I have finished making the "secondary" locales have their
own date format string (whose legacy name was "tformat").

It took me a while since I went down a lot of blind alleys
and had some dead ends, but I think it works now.

I especially want to thank John whose suggestion to seed the
date format string (rather than looking it up externally to
gramps) made things a lot better, a lot cleaner.  Thanks!

I enclose the compatible version of my earlier patch to add
a date-format option to reports.  (As before, that patch
also has a patched Complete Individual report, for testing.)

So I am uploading both of them, in the hope some of you will
be willing to review them or test them, and ideally both.

I had to make quite a few changes to the date handler code
to get it to work, and so the more eyes which look it over,
the better.

I think I can explain and justify anything you wonder about
but I will admit the possibility that some leftover artifact
of a dead end might still be in there, somewhere.  And also
some of my memories might be pretty vague by now.  8-(

The legacy way in which the English date handler takes care
of many other languages caused me lots of problems for
instance, and I tried lots of approaches earlier.

Anyway, here they are.

====================================================

Edit:

The above words were written when I emailed both patches
(and those words) to the list, but the "list moderator"
didn't allow it to be sent to you, since the total number of
characters was too large, about twice the 40k limit.

So I filed a bug report for the bug, that secondary locales
cannot have their own numeric date format string, and
uploaded my patch to fix that bug to the bug report.

So only my revised date-format-option patch is attached to
this email, although it requires the bug to be fixed first.

I apologize for the inconvenience, in testing both of them.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

20170312A=report-dates.trunk.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 3/15/17, Paul Franklin <[hidden email]> wrote:
> So I filed a bug report for the bug, that secondary locales
> cannot have their own numeric date format string, and
> uploaded my patch to fix that bug to the bug report.

https://gramps-project.org/bugs/view.php?id=9985

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Josip
In reply to this post by Paul Franklin-5
15.3.2017. u 19:51, Paul Franklin je napisao/la:

> I have finished making the "secondary" locales have their
> own date format string (whose legacy name was "tformat").
>
> It took me a while since I went down a lot of blind alleys
> and had some dead ends, but I think it works now.
>
> I especially want to thank John whose suggestion to seed the
> date format string (rather than looking it up externally to
> gramps) made things a lot better, a lot cleaner.  Thanks!
>
> I enclose the compatible version of my earlier patch to add
> a date-format option to reports.  (As before, that patch
> also has a patched Complete Individual report, for testing.)
>
> So I am uploading both of them, in the hope some of you will
> be willing to review them or test them, and ideally both.
>
> I had to make quite a few changes to the date handler code
> to get it to work, and so the more eyes which look it over,
> the better.
>
> I think I can explain and justify anything you wonder about
> but I will admit the possibility that some leftover artifact
> of a dead end might still be in there, somewhere.  And also
> some of my memories might be pretty vague by now.  8-(
>
> The legacy way in which the English date handler takes care
> of many other languages caused me lots of problems for
> instance, and I tried lots of approaches earlier.
>
> Anyway, here they are.
>
> ====================================================
>
> Edit:
>
> The above words were written when I emailed both patches
> (and those words) to the list, but the "list moderator"
> didn't allow it to be sent to you, since the total number of
> characters was too large, about twice the 40k limit.
>
> So I filed a bug report for the bug, that secondary locales
> cannot have their own numeric date format string, and
> uploaded my patch to fix that bug to the bug report.
>
> So only my revised date-format-option patch is attached to
> this email, although it requires the bug to be fixed first.
>
> I apologize for the inconvenience, in testing both of them.
>

For me on Windows it looks OK.
I can select any language and date format change to that.
I don't know most of those languages so can't verify that format is
always correct but if i start Gramps in other language and choose to run
CIR in my language list of date format is correct.

--
Josip

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

Paul Franklin-5
On 3/18/17, Josip <[hidden email]> wrote:
> For me on Windows it looks OK.
> I can select any language and date format change to that.
> I don't know most of those languages so can't verify that format is
> always correct but if i start Gramps in other language and choose to run
> CIR in my language list of date format is correct.

Thank you for the feedback.  I appreciate it.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: proposed patch (date-format report option)

dave.khuon@gmail.com
In reply to this post by Paul Franklin-5
Hi all,

I appreciate being included for testing and bug reporting for this product.
I am a newbie to this forum.  My past experiences were primarily MS  .Net /
C#, some coding experiences in Java and Python.  I am a retired programmer,
and am thrilled for the possibility to get busy on some good cause projects.

I am currently setting up a development environment (LiClipse) by following
the guideline of "Getting started with Gramps development", in order to
further my understanding of Gramps.  I am wondering if later I could get
some helps from anyone here, if I run into trouble.

I am interested in customizing (add-on) Descendent Reports, and the build
process required to submit my add-ons.  Nonetheless, I welcome any
opportunity to serve, for this project.  

Thanks,
-dave

-----Original Message-----
From: Paul Franklin [mailto:[hidden email]]
Sent: Saturday, March 18, 2017 10:52 AM
To: [hidden email]
Subject: Re: [Gramps-devel] proposed patch (date-format report option)

On 3/15/17, Paul Franklin <[hidden email]> wrote:
> So I filed a bug report for the bug, that secondary locales cannot
> have their own numeric date format string, and uploaded my patch to
> fix that bug to the bug report.

https://gramps-project.org/bugs/view.php?id=9985

----------------------------------------------------------------------------
--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12345