From: Arturas S. <asl...@ce...> - 2006-02-24 19:01:15
|
Hello, I tested Calendar plugin - it works great, I'll have some nice presents for next Cristmas. But I have few points: 1. flag "Use maiden names" - looks like it is working in oposite way - When I do not select - it shows surname of women before weeding, if it checked it shows something (probably Family name). 2. This something: In our country (Lithuania) surnames for husband and wife are a little bit different (another ending of Surname). Example: my surname is Sleinius, mine wife is Sleiniene. For Surnames after weeding for womens in GRAMPS I'm adding in Names tab new Surname of type "Weeding name" - This seems to be ignored at all. (This is only for information as I'll still pan to use maiden surnames). 3. If there is anniversary of weeding then in calendar it is shown: both wife and husband and untranslated "and" in middle (also number at the end) - maybe it is possible to use translated string in this place? (it is the only english I see on whole calendar). Thanks, Arturas Sleinius <--------------------===================================--------------------> DELFI mail pašto sistema http://www.mail.lt |
From: Douglas S. B. <db...@br...> - 2006-02-24 20:08:34
|
On Fri, 2006-02-24 at 21:00 +0200, Arturas Sleinius wrote: > Hello, >=20 > I tested Calendar plugin - it works great, I'll have some nice > presents for next Cristmas. =20 Arturas, Thanks for the feedback. I use the calendar for christmas presents too, and was my main motivation for creating it! > But I have few points: > 1. flag "Use maiden names" - looks like it is working in oposite > way - When I do not select - it shows surname of women before > weeding, if it checked it shows something (probably Family name). =20 Oops, I'll take a look at that. > 2. This something: In our country (Lithuania) surnames for husband and > wife are a little bit different (another ending of Surname). Example: > my surname is Sleinius, mine wife is Sleiniene. For Surnames after > weeding for womens in GRAMPS I'm adding in Names tab new Surname of > type "Weeding name" - This seems to be ignored at all. (This is only > for information as I'll still pan to use maiden surnames). So you are saying that you would like to use a "Wedding name" if it exists? Otherwise, do what the calendar currently does? > 3. If there is anniversary of weeding then in calendar it is shown: > both wife and husband and untranslated "and" in middle (also number at > the end) - maybe it is possible to use translated string in this > place? (it is the only english I see on whole calendar). Oops! You're right. I'll work with Alex to patch the current code to fix this, and the checkbox problem above. I suspect "and" is in the translation list. Or we could use "&"... is that an universal symbol for and? -Doug > Thanks, > Arturas Sleinius=20 > <--------------------=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-------------------= -> > DELFI mail pa=C5=A1to sistema http://www.mail.lt >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live we= bcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel >=20 --=20 Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank |
From: Alex R. <sh...@gr...> - 2006-02-24 20:46:04
|
On Fri, 2006-02-24 at 15:08 -0500, Douglas S. Blank wrote: > > 3. If there is anniversary of weeding then in calendar it is shown: > > both wife and husband and untranslated "and" in middle (also number at > > the end) - maybe it is possible to use translated string in this > > place? (it is the only english I see on whole calendar). >=20 > Oops! You're right. I'll work with Alex to patch the current code to fix > this, and the checkbox problem above. I suspect "and" is in the > translation list. Or we could use "&"... is that an universal symbol for > and? If I'm not mistaken, the code is this (anniversary): "%s and\n %s, %d" % (spouse_name, short_name, years) We could either use '&' or translate the whole thing. The strings like _("%s and\n %s, %d") may be confusing to the translator, because the context is missing. So if we went with translating the whole phrase, the better thing would be to do something like: _("%(spouse)s and\n %(person)s, %(nyears)d") % { 'spouse' : spouse_name, 'person' : short_name, 'nyears' : years, } so that the translators would get the context. We tend to stick to these forms for complex phrases, because sometimes translators may need to change the order of format line parameters etc. In this case it seems that just translating "and" may be enough, but one can never be sure about all languages :-) We also have a wiki page on this: http://developers.gramps-project.org/tiki-index.php?page=3DCodingForTransla= tions Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Julio S. <jul...@gm...> - 2006-02-25 08:52:38
|
2006/2/24, Alex Roitman <sh...@gr...>: > > On Fri, 2006-02-24 at 15:08 -0500, Douglas S. Blank wrote: > > > 3. If there is anniversary of weeding then in calendar it is shown: > > > both wife and husband and untranslated "and" in middle (also number a= t > > > the end) - maybe it is possible to use translated string in this > > > place? (it is the only english I see on whole calendar). > > > > Oops! You're right. I'll work with Alex to patch the current code to fi= x > > this, and the checkbox problem above. I suspect "and" is in the > > translation list. Or we could use "&"... is that an universal symbol fo= r > > and? > > If I'm not mistaken, the code is this (anniversary): > "%s and\n %s, %d" % (spouse_name, short_name, years) > > We could either use '&' or translate the whole thing. The usage of & in Spanish, while recognized, sounds always foreign. While speaking, we would use 'y' or 'e' depending on the starting letter in the next work, so we would probably translate it as 'con', since it removes som= e ambiguity with multiple surnames In other context we might use other symbols (a cross, similar to a large 'x', is frequent). So, please, leave the whole string for translation. Regards, Julio |
From: Alex R. <sh...@gr...> - 2006-02-25 06:24:29
|
Doug, I was running CLI tests before the release, and found that options_help dict of the CalendarOptions instance in the Calendar.py contains this: { 'maiden_name': ('=3D0/1',"Use married women's maiden name.", "Select to use married women's maiden name."), 'anniversaries': ('=3D0/1','Include anniversaries', 'Select to include anniversaries'), 'title': (None, None, None), 'text': (None, None, None), 'text2style': (None, None, None), 'birthdays': ('=3D0/1', 'Include birthdays', 'Select to include birthda= ys'), 'alive': ('=3D0/1', 'Include only living people', 'Select to only include living people'), 'holidays': ('=3D0/1', 'Include holidays', 'Select to include holidays'= ), 'text2': ('=3Dstr', 'Medium size text', 'Any text'), 'text3': ('=3Dstr', 'Small text area', 'Any text'), 'text1': ('=3Dstr', 'Large text area', 'Any text'), 'numbers': (None, None, None), 'offset': ('=3Dnum', 'Distance to move text on page', 'Any number'), 'year': ('=3Dnum', 'Year of calendar', 'Any year'), 'text3style': (None, None, None), 'text1style': (None, None, None), 'daynames': (None, None, None), 'border': (None, None, None) } There is a problem with options whose help values contain None. The self-documentation system relies on help values being strings. So, can these be changed? I am not sure that just replacing None with empty strings is useful. It's late now and I don't even pretend to understand what is going on with those style things. But I'm thinking that you may be able to answer it right away :-) If these are indeed styles and not options, can they be removed from the CalendarOptions? The other reports do it this way, and the style is specified as a whole by style name, not by individual style elements. If these are options visible from the report dialog (as opposed to Style Editor), then can they use more meaningful help strings? Thanks, Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: <db...@br...> - 2006-02-25 12:47:38
|
Hmmm. I may be using that for multiple purposes. I'll have to take a detailed look. I'll try to fix this this afternoon. Also, I am "dsblank" on SourceForge. -Doug > Doug, > > I was running CLI tests before the release, and found that > options_help dict of the CalendarOptions instance in the Calendar.py > contains this: > > { > 'maiden_name': ('=3D0/1',"Use married women's maiden name.", > "Select to use married women's maiden name."), > 'anniversaries': ('=3D0/1','Include anniversaries', > 'Select to include anniversaries'), > 'title': (None, None, None), > 'text': (None, None, None), > 'text2style': (None, None, None), > 'birthdays': ('=3D0/1', 'Include birthdays', 'Select to include > birthdays'), > 'alive': ('=3D0/1', 'Include only living people', > 'Select to only include living people'), > 'holidays': ('=3D0/1', 'Include holidays', 'Select to include > holidays'), > 'text2': ('=3Dstr', 'Medium size text', 'Any text'), > 'text3': ('=3Dstr', 'Small text area', 'Any text'), > 'text1': ('=3Dstr', 'Large text area', 'Any text'), > 'numbers': (None, None, None), > 'offset': ('=3Dnum', 'Distance to move text on page', 'Any number')= , > 'year': ('=3Dnum', 'Year of calendar', 'Any year'), > 'text3style': (None, None, None), > 'text1style': (None, None, None), > 'daynames': (None, None, None), > 'border': (None, None, None) > } > > > There is a problem with options whose help values contain None. > The self-documentation system relies on help values being strings. > So, can these be changed? I am not sure that just replacing > None with empty strings is useful. It's late now and I don't > even pretend to understand what is going on with those style things. > But I'm thinking that you may be able to answer it right away :-) > > If these are indeed styles and not options, can they be removed > from the CalendarOptions? The other reports do it this way, and > the style is specified as a whole by style name, not by individual > style elements. If these are options visible from the report dialog > (as opposed to Style Editor), then can they use more meaningful > help strings? > > Thanks, > Alex > > -- > Alexander Roitman http://www.gramps-project.org > |
From: <db...@br...> - 2006-02-25 14:47:51
|
> Doug, > > I was running CLI tests before the release, and found that > options_help dict of the CalendarOptions instance in the Calendar.py > contains this: > > { > 'maiden_name': ('=3D0/1',"Use married women's maiden name.", > "Select to use married women's maiden name."), > 'anniversaries': ('=3D0/1','Include anniversaries', > 'Select to include anniversaries'), > 'title': (None, None, None), > 'text': (None, None, None), > 'text2style': (None, None, None), > 'birthdays': ('=3D0/1', 'Include birthdays', 'Select to include > birthdays'), > 'alive': ('=3D0/1', 'Include only living people', > 'Select to only include living people'), > 'holidays': ('=3D0/1', 'Include holidays', 'Select to include > holidays'), > 'text2': ('=3Dstr', 'Medium size text', 'Any text'), > 'text3': ('=3Dstr', 'Small text area', 'Any text'), > 'text1': ('=3Dstr', 'Large text area', 'Any text'), > 'numbers': (None, None, None), > 'offset': ('=3Dnum', 'Distance to move text on page', 'Any number')= , > 'year': ('=3Dnum', 'Year of calendar', 'Any year'), > 'text3style': (None, None, None), > 'text1style': (None, None, None), > 'daynames': (None, None, None), > 'border': (None, None, None) > } > > > There is a problem with options whose help values contain None. > The self-documentation system relies on help values being strings. > So, can these be changed? I am not sure that just replacing > None with empty strings is useful. It's late now and I don't > even pretend to understand what is going on with those style things. > But I'm thinking that you may be able to answer it right away :-) > > If these are indeed styles and not options, can they be removed > from the CalendarOptions? The other reports do it this way, and > the style is specified as a whole by style name, not by individual > style elements. If these are options visible from the report dialog > (as opposed to Style Editor), then can they use more meaningful > help strings? Alex, Ok, I think that this is easy to fix. The problem was that I was trying t= o make all graphical objects have the same kind of interface in reports. Whether it is a spinner, checkbox, filter, or style, they all get treated in a consistent manner. It may be that you want to have help for styles. But, I'll assume that yo= u don't. To remove them from the options_help dictionary, just change the register method of the base Widget class, around line 388: ---- def register(self): className =3D self.__class__.__name__ if className =3D=3D "FilterWidget": self.option_object.enable_dict['filter'] =3D 0 elif className =3D=3D "StyleWidget": self.option_object[self["name"]] =3D self["value"] else: self.option_object[self["name"]] =3D self["value"] self.option_object.options_help[self["name"]] =3D ( self["wtype"], self["help"], self["valid_text"]) ---- and that should be fine. I don't use the options_help for anything, so that should only effect what the CLI help system does. I tested this change and the Calendar is unaffected. I'll be out-of-town till Sunday night. I'll check back then, try everything out, see if I have SourceForge access, and see if the "and" English problem, and reversed married-name/maiden-name checkbox issues ar= e fixed (and fix them otherwise). Thanks for all the help in testing and integrating this into gramps. I hope that wrestling with the Widgets will make report writing easier (and other things possible) soon. -Doug > Thanks, > Alex > > -- > Alexander Roitman http://www.gramps-project.org > |
From: Alex R. <sh...@gr...> - 2006-02-26 16:52:08
|
Doug, On Sat, 2006-02-25 at 09:47 -0500, db...@br... wrote: >=20 > Ok, I think that this is easy to fix. The problem was that I was trying t= o > make all graphical objects have the same kind of interface in reports. > Whether it is a spinner, checkbox, filter, or style, they all get treated > in a consistent manner. >=20 > It may be that you want to have help for styles. But, I'll assume that yo= u > don't. To remove them from the options_help dictionary, just change the > register method of the base Widget class, around line 388: > ---- > def register(self): > className =3D self.__class__.__name__ > if className =3D=3D "FilterWidget": > self.option_object.enable_dict['filter'] =3D 0 > elif className =3D=3D "StyleWidget": > self.option_object[self["name"]] =3D self["value"] > else: > self.option_object[self["name"]] =3D self["value"] > self.option_object.options_help[self["name"]] =3D ( > self["wtype"], self["help"], self["valid_text"]) > ---- >=20 > and that should be fine. I don't use the options_help for anything, so > that should only effect what the CLI help system does. I tested this > change and the Calendar is unaffected. I have committed this to the CVS. > I'll be out-of-town till Sunday night. I'll check back then, try > everything out, see if I have SourceForge access, and see if the "and" > English problem, and reversed married-name/maiden-name checkbox issues ar= e > fixed (and fix them otherwise). I'll let you do the "and" translation and the checkbox since you know better where to look for them. You should have CVS access now, using -d :ext:ds...@cv...:/cvsroot/gramps but you'll need to check out the new module from the real CVS to be able to commit (don't forget "-r gramps20" branch tag). The sf.net also allows you to upload your public key so you don't have to type password for each access, see MyPage>Preferences page and follow the [Edit SSH Keys for Shell/CVS] link. If for some reason you have trouble committing, please let me know and we should be able to work it out. > Thanks for all the help in testing and integrating this into gramps. I > hope that wrestling with the Widgets will make report writing easier (and > other things possible) soon. Yes, I think we may want to move to Widgets in HEAD. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: <db...@br...> - 2006-02-27 05:40:41
|
Alex said: > I'll let you do the "and" translation and the checkbox since you > know better where to look for them. You should have CVS access now, > using -d :ext:ds...@cv...:/cvsroot/gramps > but you'll need to check out the new module from the real CVS > to be able to commit (don't forget "-r gramps20" branch tag). Alex, I've checked out gramps20, made my fixes, and committed them (and updates to ChangeLog). The docs for that report should mention some current quirk= s (I'm noting them here so I don't forget): 1) The "Use maiden name" checkbox applies to single person names. For the anniversary entries, I always use the maiden name. 2) If a person has a nickname, that first name will be used. 3) If a person has a nickname with a space in it, that will signal the calendar that that is the preferred first name AND lastname and will use that instead of the surname. (Hacky but useful for listing one woman's lastname in a sea of others that want to use their husband's lastname). 4) The offset option is used to adjust the text up and down. Set it to zero for proper PDF; set to about -0.5 for the others. Current TODO list: 1) track down text offset issue in docgen and fix; remove offset option 2) add a "Use Wedding Name, if available" option and method for entering and identifying that name 3) add a docgen bounding box so that long text will wrap appropriately Please let me know if you see anything, or if I made any mistakes. Thanks -Doug > Alex > > -- > Alexander Roitman http://www.gramps-project.org > |
From: Alex R. <sh...@gr...> - 2006-02-27 06:25:19
|
Doug, On Mon, 2006-02-27 at 00:40 -0500, db...@br... wrote: > Please let me know if you see anything, or if I made any mistakes. Everything looks good to me. Translators: Since we have a new string, I have updated the template.po in the CVS. The 2.0.10 release should happen sometime on Monday, PST (UTC -0800). If you get a chance to translate that one string, it would be nice. If not then so be it, since it was not marked as translatable before, and not translating it now will not make things worse. As always, please yell at me if you notice something horrible :-) Thanks, Alex --=20 Alexander Roitman http://www.gramps-project.org |