From: Tim L. <guy...@gm...> - 2014-08-04 17:36:38
|
Is it just me, or is this code (for around line 409 in arghandler.py) really odd? (1) In the first print statement, why is the whole string including the quoted %s translated? We know from all the other lines that there will be a translation for ("Family Tree"), so surely asking for this string to be translated is just extra work for the translator? (2) In the first print statement, won't it just be the fixed string that gets encoded? Shouldn't it be the generated string that gets encoded, like the last print statement? (3) Are the brackets round the parameter of the second print statement unnecessary, (this is Python 2.x, so brackets are not required); there are no brackets round the parameter of the first print statement? Any offers for the best code improvements for this fragment? This all seems to be done for Windows compatibility, so I can't test whether any improvement does what it is supposed to do under Windows. -- View this message in context: http://gramps.1791082.n4.nabble.com/Trivial-code-improvement-question-tp4666722.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Paul F. <pf....@gm...> - 2014-08-04 18:12:15
|
On 8/4/14, Tim Lyons <guy...@gm...> wrote: > Is it just me, or is this code (for around line 409 in arghandler.py) > really > odd? > > > > (1) In the first print statement, why is the whole string including the > quoted %s translated? We know from all the other lines that there will be a > translation for ("Family Tree"), so surely asking for this string to be > translated is just extra work for the translator? > > (2) In the first print statement, won't it just be the fixed string that > gets encoded? Shouldn't it be the generated string that gets encoded, like > the last print statement? > > (3) Are the brackets round the parameter of the second print statement > unnecessary, (this is Python 2.x, so brackets are not required); there are > no brackets round the parameter of the first print statement? > > Any offers for the best code improvements for this fragment? This all seems > to be done for Windows compatibility, so I can't test whether any > improvement does what it is supposed to do under Windows. Without investigating your questions in too much detail, I'll just mention that the colon (":") is important, in any such translation, as some languages (French for example) require a space ahead of the colon, not adjacent as it is in English. (There is a bug report about translating such punctuation marks.) So at the very least, the final print statement, in the inner loop, needs translation also. That is, the line print(" %s: %s" % (item, summary[item])) should instead be print(_(" %s: %s") % (item, summary[item])) |
From: Tim L. <guy...@gm...> - 2014-08-04 19:38:41
|
Paul Franklin-5 wrote > On 8/4/14, Tim Lyons < > guy.linton@ > > wrote: >> Is it just me, or is this code (for around line 409 in arghandler.py) >> really >> odd? >> >> >> >> (1) In the first print statement, why is the whole string including the >> quoted %s translated? We know from all the other lines that there will be >> a >> translation for ("Family Tree"), so surely asking for this string to be >> translated is just extra work for the translator? >> >> (2) In the first print statement, won't it just be the fixed string that >> gets encoded? Shouldn't it be the generated string that gets encoded, >> like >> the last print statement? >> >> (3) Are the brackets round the parameter of the second print statement >> unnecessary, (this is Python 2.x, so brackets are not required); there >> are >> no brackets round the parameter of the first print statement? >> >> Any offers for the best code improvements for this fragment? This all >> seems >> to be done for Windows compatibility, so I can't test whether any >> improvement does what it is supposed to do under Windows. > > Without investigating your questions in too much detail, > I'll just mention that the colon (":") is important, in any such > translation, as some languages (French for example) require > a space ahead of the colon, not adjacent as it is in English. > (There is a bug report about translating such punctuation marks.) > > So at the very least, the final print statement, in the inner > loop, needs translation also. That is, the line > > print(" %s: %s" % (item, summary[item])) > > should instead be > > print(_(" %s: %s") % (item, summary[item])) Thanks, that is very useful, I didn't know that. Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/Trivial-code-improvement-question-tp4666722p4666728.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Paul F. <pf....@gm...> - 2014-08-04 18:24:15
|
p.s. If you set LANG to fr_FR.utf8 and then run the "gramps -L' command, you will see an example of not only the leading-space ahead of the colon (in the first two lines) but also an example of how French uses the << and >> pair where English would use the doubled-quotation marks -- " that is to say -- which are other examples of punctation marks which need translation, even if there is no English word in the string. (I'm not sure if the time in the last-accessed line is being correctly shown in the French time-format way, however.) |
From: Paul F. <pf....@gm...> - 2014-08-04 18:47:23
|
To get even further off-topic, I'll mention that both the comma and semi-colon need to be translated too, in lines where there is no English word I mean, since the Arabic script has different characters for both (and I think the question-mark too, but that's more vague). So when I make such changes I try to put in a comment, adjacent to the line with the punctuation mark, warning why the string is being flagged for translation, just to try to minimize the chances that some future gramps developer doesn't come along and say "that string doesn't need translation, there is no word there, I'll fix it." |
From: Paul F. <pf....@gm...> - 2014-08-04 19:21:49
|
> (3) Are the brackets round the parameter of the second print statement > unnecessary, (this is Python 2.x, so brackets are not required); there are > no brackets round the parameter of the first print statement? Again without delving too deeply into your question, I'll just mention that all gramps code is supposed to be written in such a fashion that it will run on Python3, since some of our distributions (Arch and its derivatives for instance) only provide Python3. |
From: Tim L. <guy...@gm...> - 2014-08-04 19:24:40
|
On 4 Aug 2014, at 20:21, Paul Franklin wrote: >> (3) Are the brackets round the parameter of the second print >> statement >> unnecessary, (this is Python 2.x, so brackets are not required); >> there are >> no brackets round the parameter of the first print statement? > > Again without delving too deeply into your question, I'll > just mention that all gramps code is supposed to be written > in such a fashion that it will run on Python3, since some > of our distributions (Arch and its derivatives for instance) > only provide Python3. No, that only applies to Gramps 4.x; I forgot to mention that this is Gramps 3.4.x |
From: John R. <jr...@ce...> - 2014-08-04 19:53:01
|
On Aug 4, 2014, at 10:36 AM, Tim Lyons <guy...@gm...> wrote: > Is it just me, or is this code (for around line 409 in arghandler.py) really > odd? > > > > (1) In the first print statement, why is the whole string including the > quoted %s translated? We know from all the other lines that there will be a > translation for ("Family Tree"), so surely asking for this string to be > translated is just extra work for the translator? > > (2) In the first print statement, won't it just be the fixed string that > gets encoded? Shouldn't it be the generated string that gets encoded, like > the last print statement? > > (3) Are the brackets round the parameter of the second print statement > unnecessary, (this is Python 2.x, so brackets are not required); there are > no brackets round the parameter of the first print statement? > > Any offers for the best code improvements for this fragment? This all seems > to be done for Windows compatibility, so I can't test whether any > improvement does what it is supposed to do under Windows. The code snippet got lost between Nabble and the list, so here it is: for summary in sorted(summary_list, key=lambda sum: sum[_("Family tree")].lower()): print _("Family Tree \"%s\":").\ encode(sys.getfilesystemencoding()) % summary[_("Family tree")] for item in sorted(summary): if item == _("Path"): summary[item] = (summary[item]).decode(sys.getfilesystemencoding()) if item != _("Family tree"): print (" %s: %s" % (item, summary[item])).\ encode(sys.getfilesystemencoding()) 1: In some locales the order of the sentence "Family Tree blah blah:" might be expressed as something like "The blah blah Family Tree:", so the msgstr for it would be "The %s Family Tree:" (in the locale language, of course). 2. Perhaps the value of summary[_("Family Tree")] is already encoded; note the 'if item = _("Path")' clause, where it's decoded in preparation for falling through to that last print statement. 3. My preference would be to keep the round brackets and remove the continuation "\", and apply the same to the first print statement, but that's a style preference. The code compiles and executes fine either way. Maintenance branches are not the place to be doing gratuitous cleanup, especially if you can't test the results on all platforms. You're just creating an unnecessary risk of bugs. Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2014-08-08 17:51:48
|
On 4 Aug 2014, at 20:52, John Ralls wrote: > > On Aug 4, 2014, at 10:36 AM, Tim Lyons <guy...@gm...> wrote: > >> Is it just me, or is this code (for around line 409 in >> arghandler.py) really >> odd? >> >> >> >> (1) In the first print statement, why is the whole string including >> the >> quoted %s translated? We know from all the other lines that there >> will be a >> translation for ("Family Tree"), so surely asking for this string >> to be >> translated is just extra work for the translator? >> >> (2) In the first print statement, won't it just be the fixed string >> that >> gets encoded? Shouldn't it be the generated string that gets >> encoded, like >> the last print statement? >> >> (3) Are the brackets round the parameter of the second print >> statement >> unnecessary, (this is Python 2.x, so brackets are not required); >> there are >> no brackets round the parameter of the first print statement? >> >> Any offers for the best code improvements for this fragment? This >> all seems >> to be done for Windows compatibility, so I can't test whether any >> improvement does what it is supposed to do under Windows. > > The code snippet got lost between Nabble and the list, so here it is: > > for summary in sorted(summary_list, > key=lambda sum: sum[_("Family > tree")].lower()): > print _("Family Tree \"%s\":").\ > encode(sys.getfilesystemencoding()) % > summary[_("Family tree")] > for item in sorted(summary): > if item == _("Path"): > summary[item] = > (summary[item]).decode(sys.getfilesystemencoding()) > if item != _("Family tree"): > print (" %s: %s" % (item, summary[item])).\ > encode(sys.getfilesystemencoding()) > > 1: In some locales the order of the sentence "Family Tree blah > blah:" might be expressed as something like "The blah blah Family > Tree:", so the msgstr for it would be "The %s Family Tree:" (in the > locale language, of course). > > 2. Perhaps the value of summary[_("Family Tree")] is already > encoded; note the 'if item = _("Path")' clause, where it's decoded > in preparation for falling through to that last print statement. > > 3. My preference would be to keep the round brackets and remove the > continuation "\", and apply the same to the first print statement, > but that's a style preference. The code compiles and executes fine > either way. > > Maintenance branches are not the place to be doing gratuitous > cleanup, especially if you can't test the results on all platforms. > You're just creating an unnecessary risk of bugs. Thanks to everybody for their comments. I thought it was just a simple question, but the comments were very interesting and actually very relevant things to think about for other coding. John's comment about 'gratuitous cleanup' is accepted. But actually, I wasn't going to change that block; I need to change the next block that deals with generating a tab delimited list; this doesn't work, because the spaces that 'print(x,)' inserts interfere with the interpretation of the output quoted strings. I regard that as a bug, not an improvement (since the only purpose of tab delimited is to be interpreted by Excel etc). I asked about the other section of code, because it has more examples of different constructs that I wanted to understand. Thanks again, Tim. |