Quantcast

proposed patch (date-format report option)

classic Classic list List threaded Threaded
81 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

proposed patch (date-format report option)

Paul Franklin-5
I wonder if anybody is interested in testing or reviewing a
proposed patch?

It implements something I've thought of for a long time,
allowing reports to have a localized date-format option.

I know that some of you aren't very interested in reports,
but others might recall that back in 2011 a power user first
added an option to reports which allowed the user to change
the name-display format for that report, without affecting
the global name-display format [1]. (Thanks, Matt.)

Then in late 2012 and early 2013 John made the GrampsLocale
class, and then added a report option which allowed the user
to change the output language [2].  (Thanks, John.)

So this patch continues that approach, giving the user more
flexibility to tailor the report if she wants to.

It changes the report's local date-display format with no
effect on the global date-display format.

Yet since the user can control the language (locale) which
the report will be in, this new date-format option clearly
needed to cope with whatever locale the user selected, also.

But many locales have their own date handler, based on the
typical date formats in their language.  But those formats
are not universal; they depend on the language's culture,
etc.  One has only two choices, while one offers eight.

So it was somewhat tricky to implement this option, since I
had to pay attention to two user-settable option choices.

It seemed like signals might work and so I had to learn how
to use one.  While I think I got it right, it'd be nice if
people who understand them better than I do reviewed it.

But while this proposed patch seems to work for me, in the
tests I imagined to try, other imaginations may come up with
something I haven't considered.  I'd rather have that happen
now than have some user report it, later.

So the attached patch contains the option implementation as
well as a typical use, in the Complete Individual report.

Thanks.


[1] https://gramps-project.org/bugs/view.php?id=5149

[2] https://gramps-project.org/bugs/view.php?id=6210

------------------------------------------------------------------------------
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

20170224A=report-dates.trunk.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Josip
25.2.2017. u 21:18, Paul Franklin je napisao/la:
> I wonder if anybody is interested in testing or reviewing a
> proposed patch?
>

Very nice and long awaited!

I understand why date format are in chosen language only but also think
that user my have problem using it and will probably ask for their
translation. Can you add another sentence to existing one in dropdown
list tool-tip which explain that (i see that you try to reuse existing
translation so i ask for two different ones, one new + one old)
Bellow "Date format" label i will like to see one with example of chosen
format.

Date Format: [dropdown list]
  example: $TODAY

Where $TODAY will be today date in chosen format.

One again it will be a very nice addition to the Gramps report system
(didn't much look at code so not commenting that)

--
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

> 25.2.2017. u 21:18, Paul Franklin je napisao/la:
>> I wonder if anybody is interested in testing or reviewing a
>> proposed patch?
>>
>
> Very nice and long awaited!
>
> I understand why date format are in chosen language only but also think
> that user my have problem using it and will probably ask for their
> translation. Can you add another sentence to existing one in dropdown
> list tool-tip which explain that (i see that you try to reuse existing
> translation so i ask for two different ones, one new + one old)
> Bellow "Date format" label i will like to see one with example of chosen
> format.
>
> Date Format: [dropdown list]
>   example: $TODAY
>
> Where $TODAY will be today date in chosen format.
>
> One again it will be a very nice addition to the Gramps report system
> (didn't much look at code so not commenting that)
>

Thanks for the testing!

I will think about what you've suggested, but I don't
know a lot about the translation system (gettext and
so on), so I can't immediately think of a command
which I can feed a translated string to and have it
tell me the corresponding (untranslated) English
string, which I could then translate into the user's
UI language.  Can somebody tell me?

But part of the problem is that date formats are not
in any standardized format (the way there are internal
representations for the name format choices).  Some
of the locales just use the base (English) handler
but provide localized translations.  But if the English
original was MON (in capitals), there is no way to
automatically translate that into what it really is, the
"short form" of a month's name.  You just have to try
it and see, then remember.  (I've never understood
that, why DAY is used for instance, when it is just a
number, the same as always.)

(I think it would be a lot more work to write a date-format
editor, the way we now have a name-format editor, which
allows the user to create their own formats.  Mind you,
I long ago submitted a feature request for it.  I just don't
think it will ever happen.)

So an example might be a good idea, as you suggest.

I'll have to think about where to put it, since I am also
trying to keep each report dialog less than 600 pixels,
the current limit.

I don't know of a way to have each line in a combo
dropdown have its own tooltip text.  The tooltip is just
for the entire date-format option itself.  Unless a GUI
expert can tell me how, I guess.

Maybe I could put an example date on the choice line,
in parentheses?  I'll see.

Thanks again.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Nick Hall
In reply to this post by Josip
On 26/02/17 15:23, Josip wrote:
> One again it will be a very nice addition to the Gramps report system
> (didn't much look at code so not commenting that)

The code looks fairly good.  However, a couple of changes are needed:

1. The new 'trans-changed' signal in the enumerated list is not actually
used.

2. The code that rebuilds the list after the translation is changed
should reuse parts of the code that builds it initially.

Nick.



------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

On Feb 26, 2017, at 9:03 AM, Paul Franklin <[hidden email]> wrote:

On 2/26/17, Josip <[hidden email]> wrote:
25.2.2017. u 21:18, Paul Franklin je napisao/la:
I wonder if anybody is interested in testing or reviewing a
proposed patch?


Very nice and long awaited!

I understand why date format are in chosen language only but also think
that user my have problem using it and will probably ask for their
translation. Can you add another sentence to existing one in dropdown
list tool-tip which explain that (i see that you try to reuse existing
translation so i ask for two different ones, one new + one old)
Bellow "Date format" label i will like to see one with example of chosen
format.

Date Format: [dropdown list]
 example: $TODAY

Where $TODAY will be today date in chosen format.

One again it will be a very nice addition to the Gramps report system
(didn't much look at code so not commenting that)


Thanks for the testing!

I will think about what you've suggested, but I don't
know a lot about the translation system (gettext and
so on), so I can't immediately think of a command
which I can feed a translated string to and have it
tell me the corresponding (untranslated) English
string, which I could then translate into the user's
UI language.  Can somebody tell me?

But part of the problem is that date formats are not
in any standardized format (the way there are internal
representations for the name format choices).  Some
of the locales just use the base (English) handler
but provide localized translations.  But if the English
original was MON (in capitals), there is no way to
automatically translate that into what it really is, the
"short form" of a month's name.  You just have to try
it and see, then remember.  (I've never understood
that, why DAY is used for instance, when it is just a
number, the same as always.)

(I think it would be a lot more work to write a date-format
editor, the way we now have a name-format editor, which
allows the user to create their own formats.  Mind you,
I long ago submitted a feature request for it.  I just don't
think it will ever happen.)

So an example might be a good idea, as you suggest.

I'll have to think about where to put it, since I am also
trying to keep each report dialog less than 600 pixels,
the current limit.

I don't know of a way to have each line in a combo
dropdown have its own tooltip text.  The tooltip is just
for the entire date-format option itself.  Unless a GUI
expert can tell me how, I guess.

Maybe I could put an example date on the choice line,
in parentheses?  I'll see.

Paul,

To find the untranslated string (msgid) for a translated one (msgstr), open the appropriate po file with something that you can search with; 'less' works well from the Unix command line. Search for the msgstr; the msgid will be immediately before, and there are often comments before the msgid with files and line numbers where the msgid occurs. There may be more than one msgid that translates to what you're searching for, so look at every instance.

You're correct that there's no way to put separate tooltips on combobox items. You could programmatically change the tooltip based on the *selected* item in the combo box, but I think doing so would be more confusing than helpful.

Tooltips take a single string, so one can't create a tooltip with two msgids and end up with a partly-translated tooltip.

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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

>> I will think about what you've suggested, but I don't
>> know a lot about the translation system (gettext and
>> so on), so I can't immediately think of a command
>> which I can feed a translated string to and have it
>> tell me the corresponding (untranslated) English
>> string, which I could then translate into the user's
>> UI language.  Can somebody tell me?

> To find the untranslated string (msgid) for a translated one (msgstr), open
> the appropriate po file with something that you can search with; 'less'
> works well from the Unix command line. Search for the msgstr; the msgid will
> be immediately before, and there are often comments before the msgid with
> files and line numbers where the msgid occurs. There may be more than one
> msgid that translates to what you're searching for, so look at every
> instance.

Yes, I'm already aware of how to do it manually.

I didn't explain clearly enough that I don't know of a
way to do it in Python, inside gramps that is to say.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

> 1. The new 'trans-changed' signal in the enumerated list is not actually
> used.

Good point.  Thanks!  That was clearly something I
tried but I no longer remember why I didn't use it.

> 2. The code that rebuilds the list after the translation is changed
> should reuse parts of the code that builds it initially.

Do you mean to copy-and-paste so that the same
way is done both times?  Or do you mean to put the
code into its own internal method and call it from
both places?  I never thought of that but it should work.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Josip
In reply to this post by Paul Franklin-5
26.2.2017. u 18:03, Paul Franklin je napisao/la:

> On 2/26/17, Josip <[hidden email]> wrote:
>> 25.2.2017. u 21:18, Paul Franklin je napisao/la:
>>> I wonder if anybody is interested in testing or reviewing a
>>> proposed patch?
>>>
>>
>> Very nice and long awaited!
>>
>> I understand why date format are in chosen language only but also think
>> that user my have problem using it and will probably ask for their
>> translation. Can you add another sentence to existing one in dropdown
>> list tool-tip which explain that (i see that you try to reuse existing
>> translation so i ask for two different ones, one new + one old)
>> Bellow "Date format" label i will like to see one with example of chosen
>> format.
>>
>> Date Format: [dropdown list]
>>   example: $TODAY
>>
>> Where $TODAY will be today date in chosen format.
>>
>> One again it will be a very nice addition to the Gramps report system
>> (didn't much look at code so not commenting that)
>>
>
> Thanks for the testing!
>
> I will think about what you've suggested, but I don't
> know a lot about the translation system (gettext and
> so on), so I can't immediately think of a command
> which I can feed a translated string to and have it
> tell me the corresponding (untranslated) English
> string, which I could then translate into the user's
> UI language.  Can somebody tell me?
>
> But part of the problem is that date formats are not
> in any standardized format (the way there are internal
> representations for the name format choices).  Some
> of the locales just use the base (English) handler
> but provide localized translations.  But if the English
> original was MON (in capitals), there is no way to
> automatically translate that into what it really is, the
> "short form" of a month's name.  You just have to try
> it and see, then remember.  (I've never understood
> that, why DAY is used for instance, when it is just a
> number, the same as always.)
>
> (I think it would be a lot more work to write a date-format
> editor, the way we now have a name-format editor, which
> allows the user to create their own formats.  Mind you,
> I long ago submitted a feature request for it.  I just don't
> think it will ever happen.)
>
> So an example might be a good idea, as you suggest.
>
> I'll have to think about where to put it, since I am also
> trying to keep each report dialog less than 600 pixels,
> the current limit.
>
> I don't know of a way to have each line in a combo
> dropdown have its own tooltip text.  The tooltip is just
> for the entire date-format option itself.  Unless a GUI
> expert can tell me how, I guess.
>
> Maybe I could put an example date on the choice line,
> in parentheses?  I'll see.
>
> Thanks again.
>

We misunderstand each other (hence the importance of good translation)

By tooltip i meant existing one for combo dropdown (not new one for
every item in list) which is now: "Select the format to display dates"
to be expanded with something like (English speaker will formulate it
better): "This is a list of date format in language chosen above.
Select one to be used in report. Example of today date in selected
format will be shown (where?)"

If by choice line you think of label "Date format" i agree but keep in
mind that some translation of that label can be longer then that and
that some date format are quite long

--
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

> We misunderstand each other (hence the importance of good translation)

8-)

> By tooltip i meant existing one for combo dropdown (not new one for
> every item in list) which is now: "Select the format to display dates"
> to be expanded with something like (English speaker will formulate it
> better): "This is a list of date format in language chosen above.
> Select one to be used in report. Example of today date in selected
> format will be shown (where?)"

OK.  I will think about the "master" tooltip's wording.
(Remember it is also typed out in the CLI "show".)

But it seems to me that some things are implied.
That is, it's an option in a report dialog, so I would
assume that a user would realize the option will
(somehow) affect the report, and not have to be told.

>> 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.

> If by choice line you think of label "Date format" i agree but keep in
> mind that some translation of that label can be longer then that and
> that some date format are quite long

No, I meant the various combo-choice lines, the pull-down
list of the various possibilities, each possible date format.

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.

Thanks again, for the feedback.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

> On Feb 26, 2017, at 11:02 AM, Paul Franklin <[hidden email]> wrote:
>
> On 2/26/17, John Ralls <[hidden email]> wrote:
>
>>> I will think about what you've suggested, but I don't
>>> know a lot about the translation system (gettext and
>>> so on), so I can't immediately think of a command
>>> which I can feed a translated string to and have it
>>> tell me the corresponding (untranslated) English
>>> string, which I could then translate into the user's
>>> UI language.  Can somebody tell me?
>
>> To find the untranslated string (msgid) for a translated one (msgstr), open
>> the appropriate po file with something that you can search with; 'less'
>> works well from the Unix command line. Search for the msgstr; the msgid will
>> be immediately before, and there are often comments before the msgid with
>> files and line numbers where the msgid occurs. There may be more than one
>> msgid that translates to what you're searching for, so look at every
>> instance.
>
> Yes, I'm already aware of how to do it manually.
>
> I didn't explain clearly enough that I don't know of a
> way to do it in Python, inside gramps that is to say.

Paul,

Ah, sorry to have misunderstood. Gettext provides no API for that, you'd have to write your own function using the gettext sources as a guide. I don't think it would be an easy job.

If you need the msgid for something that's specified in a builder file and so translated by GtkBuilder, remove the tooltip attribute from the builder file and set it in code after building.

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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

John Ralls-2

> On Feb 26, 2017, at 12:28 PM, John Ralls <[hidden email]> wrote:
>
>
>> On Feb 26, 2017, at 11:02 AM, Paul Franklin <[hidden email]> wrote:
>>
>> On 2/26/17, John Ralls <[hidden email]> wrote:
>>
>>>> I will think about what you've suggested, but I don't
>>>> know a lot about the translation system (gettext and
>>>> so on), so I can't immediately think of a command
>>>> which I can feed a translated string to and have it
>>>> tell me the corresponding (untranslated) English
>>>> string, which I could then translate into the user's
>>>> UI language.  Can somebody tell me?
>>
>>> To find the untranslated string (msgid) for a translated one (msgstr), open
>>> the appropriate po file with something that you can search with; 'less'
>>> works well from the Unix command line. Search for the msgstr; the msgid will
>>> be immediately before, and there are often comments before the msgid with
>>> files and line numbers where the msgid occurs. There may be more than one
>>> msgid that translates to what you're searching for, so look at every
>>> instance.
>>
>> Yes, I'm already aware of how to do it manually.
>>
>> I didn't explain clearly enough that I don't know of a
>> way to do it in Python, inside gramps that is to say.
>
> Paul,
>
> Ah, sorry to have misunderstood. Gettext provides no API for that, you'd have to write your own function using the gettext sources as a guide. I don't think it would be an easy job.
>
> If you need the msgid for something that's specified in a builder file and so translated by GtkBuilder, remove the tooltip attribute from the builder file and set it in code after building.
>

As a followup, once you have the msgid in the python file you could implement Josip's suggestion as follows:

part1 = _(originial_string)
part2 = _(new string)
combo_box.set_tooltip("%s\n%s" % (part1, part2))

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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

jerome
In reply to this post by Paul Franklin-5
> To find the untranslated string (msgid) for a translated one
 (msgstr), open the appropriate po file with something that
 you can search with; 'less' works well from the Unix
 command line.

I am using some set of commands.
'grep' and 'git grep' work fine for simple search.

$ git grep -B 3 -A 1 'msgid "Mother"' po

Could be incomplete, but we can be more specific on pattern
or indexed file names. ;-)

For finding untranslated strings, you can also try:

$ cd po
$ python3 update_po.py -u fr.po
or
$ msgattrib --untranslated fr.po


Hope this can help.
Jérôme



 -----La pièce jointe associée suit-----
 
 ------------------------------------------------------------------------------
 Check out the vibrant tech community on one of
 the world's most
 engaging tech sites,
 SlashDot.org! http://sdm.link/slashdot
 -----La pièce jointe associée suit-----
 
 _______________________________________________
 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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Paul Franklin-5
I'm sorry it's taken me so long to reply but I got
distracted and it took me hours to resolve it.

It was really a wonderful idea of Josip's to include an
example of the prospective date format.  As I said, that had
never occurred to me, and yet without it I wonder how long
this problem would have continued.

I noticed it when I happened to select Portuguese for the
language of the report, when I was testing.

You might remember that we have two different translations
for Portuguese.  We only have one date handler for their
dates though.  Those two facts are critical to understanding.

(We have three different Chinese locales (zh_CN.po and
zh_HK.po and zh_TW.po), but two different Chinese date
handlers (ZH_CN and ZH_TW).  They are handled differently
and are not a problem, since each one's register_datehandler
says it only does the locales for that flavor of Chinese.
Likewise, we have two different Norwegian locales (nb.po and
nn.po), but they are fine, since the register_datehandler in
_date_nb.py says it handles both locales.)

Part of the problem arises because the register_datehandler
in the Portuguese date handler says that it takes care of
both locales, but it lists the locales it handles like this:

('pt', 'pt_PT', 'pt_PT.UTF-8', 'pt_BR', 'pt_BR.UTF-8', 'pt',
'portuguese', 'Portuguese')

(It's all on one line in _date_pt.py but of course it could
be split, which is what I suspect my mailer will do to it.)

Notice the first locale is 'pt' -- and yet there is another
'pt' deeper in.  It has been that way since that file was
created.  I checked back (10 Oct 2007).

But only the first 'pt' matters.  It matters because in
gen/datehandler/_datehandler.py, in register_datehandler we
have the line (one, no matter how it looks in this email):

parse_class._locale = display_class._locale = GrampsLocale(lang=locales[0])

That means that for all seven (or eight) locales in the
_date_pt.py register_datehandler command, they will all be
assigned the same GrampsLocale, namely for lang=locales[0]
or 'pt' since it is first.

The other part of the problem, besides it being first, is in
GrampsLocale's _init_secondary_locale method.  That method
goes about testing for various things, to try to set the
self.language attribute.  One of the things it does is call
check_available_translations(self.lang) (where self.lang is
'pt' remember, since that's what GrampsLocale was called
with).

The problem is is that it doesn't find a gramps translation
(locale) for 'pt' (since they are 'pt_BR' and 'pt_PT').  So
it falls through that test.

But the next test is

if not self.language and _first.language

and we do indeed have a _first.language -- it's 'en' -- and
so that is what self.language is set to for Portuguese (even
though self.lang is 'pt').  But that is the only locale with
that problem.  I looked at every other possible locale and
in all cases a translation was found.

So it's only Portuguese which has the problem.

But I don't want to be the one who decides how it should be
fixed.  Maybe GrampsLocale should be changed for instance
(and that's "higher than my pay grade" as Paul-C would say).

But I worked around the problem by rearranging the locale
arguments in the register_datehandler call in _date_pt.py --
making them be

('pt_PT', 'pt_PT.UTF-8', 'pt_BR', 'pt_BR.UTF-8', 'pt', 'portuguese',
'Portuguese')

instead.  That way check_available_translations is happy,
since a pt_PT translation exists.

(That's the solution for the two Norwegian locales also,
since the register_datehandler in _date_nb.py says

('nb_NO', 'nb', 'nn_NO', 'nn', 'norsk', 'Norwegian')

and so the 'nb_NO' is turned into 'nb' and nb.po exists.)

But maybe there are problems with my workaround?  Maybe
someday we'll have two different variant locales but only
one date handler for them?  I will admit that seems
unlikely to me.  Since the Chinese dates are different
(slightly), we have two date handlers.  That seems likely to
me to be the solution we'd always choose, in such a case.

But I'm asking for somebody higher up to make that decision.

Thanks.



p.s. It's been with us a while, maybe since GrampsLocale
came along, or maybe since Vassilii reworked the date
handler code, I don't know.  But you can easily see the
problem, in gramps 4.2.5 for instance.  Just select any
report which has dates and choose either Portuguese language
for the output.  The dates will be in English.  I guess
nobody's ever done that.  (The UI works fine, since it's not
a "secondary" locale.  Portuguese dates show up just fine,
when I load in datetest.gramps.) (Of course, Preferences
must be set to a format with month names, ideally long
ones, to see the wrong months; numbers won't do.)

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Nick Hall
In reply to this post by Paul Franklin-5
On 26/02/17 19:12, Paul Franklin wrote:
2. The code that rebuilds the list after the translation is changed
should reuse parts of the code that builds it initially.
Do you mean to copy-and-paste so that the same
way is done both times?  Or do you mean to put the
code into its own internal method and call it from
both places?  I never thought of that but it should work.

Don't copy and paste.  Try to avoid repeating code.

If you have code that performs a similar function to other code, then put it in a function/method.

Nick.



------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

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

> On 26/02/17 19:12, Paul Franklin wrote:
>>> 2. The code that rebuilds the list after the translation is changed
>>> should reuse parts of the code that builds it initially.
>> Do you mean to copy-and-paste so that the same
>> way is done both times?  Or do you mean to put the
>> code into its own internal method and call it from
>> both places?  I never thought of that but it should work.
>>
> Don't copy and paste.  Try to avoid repeating code.
>
> If you have code that performs a similar function to other code, then
> put it in a function/method.

Thank you.

I understand.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Paul Franklin-5
Here is today's version of my patch, based on the feedback
I received earlier.

There are some related problems, like the Portuguese one,
which I have not included in this patch, but once again I did
put a typical usage into the Complete Individual report, so
you may test this patch if you want.  I won't include any of the
report-specific changes when I commit this feature, of course.
They will be added separately.

------------------------------------------------------------------------------
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

20170227B=report-dates.trunk.patch (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Paul Franklin-5
In reply to this post by John Ralls-2
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?

Thanks.


[1]
https://gramps-project.org/bugs/view.php?id=9159

[2]
tformat = locale.nl_langinfo(locale.D_FMT).replace('%y','%Y')
# Gramps treats dates with '-' as ISO format, so replace separator on
# locale dates that use '-' to prevent confict
tformat = tformat.replace('-', '/')

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Josip
In reply to this post by Paul Franklin-5
27.2.2017. u 20:31, Paul Franklin je napisao/la:

> Here is today's version of my patch, based on the feedback
> I received earlier.
>
> There are some related problems, like the Portuguese one,
> which I have not included in this patch, but once again I did
> put a typical usage into the Complete Individual report, so
> you may test this patch if you want.  I won't include any of the
> report-specific changes when I commit this feature, of course.
> They will be added separately.
>

I am not English speaker but new tooltip:
"The format (and language) dates will be shown in (with examples)"
looks quite confusing for me.

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 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


--
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Paul Franklin-5
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"

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 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-)

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: proposed patch (date-format report option)

Paul Franklin-5
On 2/27/17, Paul Franklin <[hidden email]> wrote:
> 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.

Remember I said earlier "There are some related problems,
like the Portuguese one, which I have not included in this patch, ..."

------------------------------------------------------------------------------
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
Loading...