Serbian DateHandler update
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
Serbian DateHandler update
by Vlada Peric
::
Rate this Message:
Hello,
I'm attaching a small update to the Serbian DateHandler. I made it consistent with the new short_months/long_months scheme and rearranged the code for better readability. As Python still cannot parse the sr_RS@latin locale correctly[1], the current version will still display dates only in latin. Once Python provides the necessary support, it will be trivial to provide both a cyrillic and latin version of the display class. It should also be noted that DateHandlers still rely on the presence of the correct locale on the system (namely, when formatting in the numerical format). [1] See upstream bug report: http://bugs.python.org/issue6668 -- Vlada Perić [sr.patch] Index: src/DateHandler/_Date_sr.py =================================================================== --- src/DateHandler/_Date_sr.py (revision 13507) +++ src/DateHandler/_Date_sr.py (working copy) @@ -234,14 +234,22 @@ """ Serbian (latin) date display class """ - # TODO: Translate these month strings: - long_months = ( u"", u"January", u"February", u"March", u"April", u"May", - u"June", u"July", u"August", u"September", u"October", - u"November", u"December" ) + long_months = ("", + u"januara", u"februara", u"marta", u"aprila", + u"maja", u"juna", u"jula", u"avgusta", + u"septembra", u"oktobra", u"novembra", u"decembra" + ) + + short_months = ("", + u"jan", u"feb", u"mar", u"apr", u"maj", u"jun", + u"jul", u"avg", u"sep", u"okt", u"nov", u"dec" + ) + + roman_months = ( + "", "I", "II", "III", "IV", "V", "VI", + "VII", "VIII", "IX", "X", "XI", "XII" + ) - short_months = ( u"", u"Jan", u"Feb", u"Mar", u"Apr", u"May", u"Jun", - u"Jul", u"Aug", u"Sep", u"Oct", u"Nov", u"Dec" ) - calendar = ( "", u" (julijanski)", u" (hebrejski)", u" (francuski republikanski)", u" (persijski)", u" (islamski)", @@ -256,58 +264,13 @@ formats = ( "GGGG-MM-DD (ISO-8601)", - "Numerički (D.M.GGGG.)", + "Numerički (DD.MM.GGGG.)", "D. MMM GGGG.", "D. Mesec GGGG.", "D. Rb GGGG." ) - roman_months = ( - "", - "I", - "II", - "III", - "IV", - "V", - "VI", - "VII", - "VIII", - "IX", - "X", - "XI", - "XII" - ) - - sr_months = ("", - u"januara", - u"februara", - u"marta", - u"aprila", - u"maja", - u"juna", - u"jula", - u"avgusta", - u"septembra", - u"oktobra", - u"novembra", - u"decembra" - ) - sr_months3 = ("", - u"jan", - u"feb", - u"mar", - u"apr", - u"maj", - u"jun", - u"jul", - u"avg", - u"sep", - u"okt", - u"nov", - u"dec" - ) - def _display_gregorian(self, date_val): """ display gregorian calendar date in different format @@ -316,6 +279,7 @@ if self.format == 0: return self.display_iso(date_val) elif self.format == 1: + ## DD.MM.YYYY. if date_val[3]: return self.display_iso(date_val) else: @@ -325,27 +289,28 @@ value = self._tformat.replace('%m', str(date_val[1])) value = value.replace('%d', str(date_val[0])) value = value.replace('%Y', str(abs(date_val[2]))) - value = value.replace('-', '/') + #some locale magic already provides the right separator + #value = value.replace('/', '.') elif self.format == 2: # Day. MON Year. if date_val[0] == 0: if date_val[1] == 0: value = u"%s." % year else: - value = u"%s %s." % (self.sr_months3[date_val[1]], year) + value = u"%s %s." % (self.short_months[date_val[1]], year) else: value = u"%d. %s %s." % (date_val[0], - self.sr_months3[date_val[1]], year) + self.short_months[date_val[1]], year) elif self.format == 3: # Day. MONTH Year. if date_val[0] == 0: if date_val[1] == 0: value = u"%s." % year else: - value = u"%s %s." % (self.sr_months[date_val[1]], year) + value = u"%s %s." % (self.long_months[date_val[1]], year) else: value = u"%d. %s %s." % (date_val[0], - self.sr_months[date_val[1]], year) + self.long_months[date_val[1]], year) else: # Day RomanMon Year if date_val[0] == 0: ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Benny Malengier
::
Rate this Message:
Vlada,
please attach to a bug ticket, and reply with bug ticket, so this does not get forgotten. Benny 2009/11/6 Vlada Peric <vlada.peric@...>: > Hello, > > I'm attaching a small update to the Serbian DateHandler. I made it > consistent with the new short_months/long_months scheme and rearranged > the code for better readability. As Python still cannot parse the > sr_RS@latin locale correctly[1], the current version will still > display dates only in latin. Once Python provides the necessary > support, it will be trivial to provide both a cyrillic and latin > version of the display class. > > It should also be noted that DateHandlers still rely on the presence > of the correct locale on the system (namely, when formatting in the > numerical format). > > [1] See upstream bug report: http://bugs.python.org/issue6668 > > -- > Vlada Perić > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Vlada Peric
::
Rate this Message:
I thought to avoid cluttering the bug tracker, but you're right, it's
probably a good idea to post it there regardless. http://www.gramps-project.org/bugs/view.php?id=3333 On Fri, Nov 6, 2009 at 1:27 PM, Benny Malengier <benny.malengier@...> wrote: > Vlada, > > please attach to a bug ticket, and reply with bug ticket, so this does > not get forgotten. > > Benny > > 2009/11/6 Vlada Peric <vlada.peric@...>: >> Hello, >> >> I'm attaching a small update to the Serbian DateHandler. I made it >> consistent with the new short_months/long_months scheme and rearranged >> the code for better readability. As Python still cannot parse the >> sr_RS@latin locale correctly[1], the current version will still >> display dates only in latin. Once Python provides the necessary >> support, it will be trivial to provide both a cyrillic and latin >> version of the display class. >> >> It should also be noted that DateHandlers still rely on the presence >> of the correct locale on the system (namely, when formatting in the >> numerical format). >> >> [1] See upstream bug report: http://bugs.python.org/issue6668 >> >> -- >> Vlada Perić >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gramps-devel@... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > -- Vlada Perić ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Brian Matherly
::
Rate this Message:
Vlada,
> It should also be noted that DateHandlers still rely on the > presence > of the correct locale on the system (namely, when > formatting in the > numerical format). I glad you brought this up. I noticed the same thing. I would be interested in your (and other people's) opinion on this. Should we manually program the number format for each language? One potential problem I can think of is that there may be different regions that use the same language, but different date formats. For example: In the U.S. we speak English and typically use the date format mm/dd/yyyy. In England, they speak English and typically use the date format dd/mm/yyyy. So the English DateHandler would be wrong for one of the two if we manually program it. Comments would be appreciated. ~Brian ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Benny Malengier
::
Rate this Message:
2009/11/6 Brian Matherly <brian@...>:
> Vlada, > >> It should also be noted that DateHandlers still rely on the >> presence >> of the correct locale on the system (namely, when >> formatting in the >> numerical format). > > I glad you brought this up. I noticed the same thing. I would be interested in your (and other people's) opinion on this. > > Should we manually program the number format for each language? > > One potential problem I can think of is that there may be different regions that use the same language, but different date formats. > > For example: > In the U.S. we speak English and typically use the date format mm/dd/yyyy. > In England, they speak English and typically use the date format dd/mm/yyyy. I would have the date handlers set it. For those handlers that serve languages where both types are used, the date handler can check the local. That is, the english date handler should check the locale and use the numeric type defined there, whereas eg the dutch date handler can just take dd/mm/yyyy. So, an english person will have a locale that says dd/mm/yyyy and an american not. Benny > > So the English DateHandler would be wrong for one of the two if we manually program it. > > Comments would be appreciated. > > ~Brian > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Brian Matherly
::
Rate this Message:
> I would have the date handlers set it. For those handlers
> that serve > languages where both types are used, the date handler can > check the > local. That is, the english date handler should check the > locale and > use the numeric type defined there, whereas eg the dutch > date handler > can just take dd/mm/yyyy. > > So, an english person will have a locale that says > dd/mm/yyyy and an > american not. Ok, consider this: The English DateHandler will be used to generate reports in any language. That is, the user will be able to select the language at run-time. So, when a Dutch user is running Gramps in Dutch, and they choose to generate a report in English, how will the date look? The date format will depend on the language of the user, not the language of the report. ~Brian ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Benny Malengier
::
Rate this Message:
2009/11/6 Brian Matherly <brian@...>:
>> I would have the date handlers set it. For those handlers >> that serve >> languages where both types are used, the date handler can >> check the >> local. That is, the english date handler should check the >> locale and >> use the numeric type defined there, whereas eg the dutch >> date handler >> can just take dd/mm/yyyy. >> >> So, an english person will have a locale that says >> dd/mm/yyyy and an >> american not. > > Ok, consider this: > > The English DateHandler will be used to generate reports in any language. That is, the user will be able to select the language at run-time. So, when a Dutch user is running Gramps in Dutch, and they choose to generate a report in English, how will the date look? The date format will depend on the language of the user, not the language of the report. As a Dutch speaker user, I would want things as dd/mm/yyyy, even when I generate US english. We don't like mm/dd/yyyy ! If I am attentive for any USA users of my website, then I choose the iso date, or more verbose months. Benny ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Brian Matherly
::
Rate this Message:
> >> I would have the date handlers set it. For those
> handlers > >> that serve > >> languages where both types are used, the date > handler can > >> check the > >> local. That is, the english date handler should > check the > >> locale and > >> use the numeric type defined there, whereas eg the > dutch > >> date handler > >> can just take dd/mm/yyyy. > >> > >> So, an english person will have a locale that > says > >> dd/mm/yyyy and an > >> american not. > > > > Ok, consider this: > > > > The English DateHandler will be used to generate > reports in any language. That is, the user will be able to > select the language at run-time. So, when a Dutch user is > running Gramps in Dutch, and they choose to generate a > report in English, how will the date look? The date format > will depend on the language of the user, not the language of > the report. > > As a Dutch speaker user, I would want things as dd/mm/yyyy, > even when > I generate US english. We don't like mm/dd/yyyy ! If I am > attentive > for any USA users of my website, then I choose the iso > date, or more > verbose months. I wonder if most people would agree with you. Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. Am I understanding correctly? What do others think? I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. Maybe we should just force ISO dates for translated reports and not follow the user preferences. ~BM ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Nick Hall-6
::
Rate this Message:
Brian Matherly wrote: >>>> I would have the date handlers set it. For those >>>> >> handlers >> >>>> that serve >>>> languages where both types are used, the date >>>> >> handler can >> >>>> check the >>>> local. That is, the english date handler should >>>> >> check the >> >>>> locale and >>>> use the numeric type defined there, whereas eg the >>>> >> dutch >> >>>> date handler >>>> can just take dd/mm/yyyy. >>>> >>>> So, an english person will have a locale that >>>> >> says >> >>>> dd/mm/yyyy and an >>>> american not. >>>> >>> Ok, consider this: >>> >>> The English DateHandler will be used to generate >>> >> reports in any language. That is, the user will be able to >> select the language at run-time. So, when a Dutch user is >> running Gramps in Dutch, and they choose to generate a >> report in English, how will the date look? The date format >> will depend on the language of the user, not the language of >> the report. >> >> As a Dutch speaker user, I would want things as dd/mm/yyyy, >> even when >> I generate US english. We don't like mm/dd/yyyy ! If I am >> attentive >> for any USA users of my website, then I choose the iso >> date, or more >> verbose months. >> > > I wonder if most people would agree with you. > > Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. > > Am I understanding correctly? > > What do others think? > > I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. > I also only speak one language and probably won't be generating reports in other languages. My locale is "en_GB". At present I can enter dates in either "dd/mm/yyyy" or "dd mmm yyyy" format which is good. In England the usual date format is "dd/mm/yyyy", however for genealogy I always use "dd mmm yyyy". On a website this would be unambiguous for English and American users. I prefer this format to ISO. If I was creating a report in a different language I would like it also to be in this format but with the month abbreviation changed accordingly. I can see why users who use a "dd/mm/yyyy" format would want it changed to "mm/dd/yyyy" for countries which use this format though. This should be on a country not language basis - a non-English speaker would need to be able to choose between "en_US" and "en_GB" to generate an English report as has already been said. Nick. > Maybe we should just force ISO dates for translated reports and not follow the user preferences. > > ~BM > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Benny Malengier
::
Rate this Message:
2009/11/6 Brian Matherly <brian@...>:
>> >> I would have the date handlers set it. For those >> handlers >> >> that serve >> >> languages where both types are used, the date >> handler can >> >> check the >> >> local. That is, the english date handler should >> check the >> >> locale and >> >> use the numeric type defined there, whereas eg the >> dutch >> >> date handler >> >> can just take dd/mm/yyyy. >> >> >> >> So, an english person will have a locale that >> says >> >> dd/mm/yyyy and an >> >> american not. >> > >> > Ok, consider this: >> > >> > The English DateHandler will be used to generate >> reports in any language. That is, the user will be able to >> select the language at run-time. So, when a Dutch user is >> running Gramps in Dutch, and they choose to generate a >> report in English, how will the date look? The date format >> will depend on the language of the user, not the language of >> the report. >> >> As a Dutch speaker user, I would want things as dd/mm/yyyy, >> even when >> I generate US english. We don't like mm/dd/yyyy ! If I am >> attentive >> for any USA users of my website, then I choose the iso >> date, or more >> verbose months. > > I wonder if most people would agree with you. > > Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. > > Am I understanding correctly? No, what I say is that the datehandler should hard code it, but that the default english date handler should have hard coded a lookup to the installed locale, and use that. On the other hand, eg the dutch datehandler has hardcoded dd/mm/yyyy. In such a scheme, we can add a en_GB and a en_US datehandler that inherit the default english datehandler, but don't look at the locale for the numeric date, but have it hardcoded. Like this, somebody with en en_ZA (Zambia, no?) would use the default english which would look at the installed locale, and hence use dd/mm/yyyy, while on generation of reports, he can choose the en_GB or en_US if he wants to. Benny > > What do others think? > > I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. > > Maybe we should just force ISO dates for translated reports and not follow the user preferences. > > ~BM > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Jerome
::
Rate this Message:
I do not understand ... numerical format displays numerical month
number. Why should be the month number set ? > One potential problem I can think of is that there may be different regions that use the same language, but different date formats. OK, maybe I understand ! ex: DateHandler for people speaking french (Canadian, Belgian, Swiss, French) have their preferred date formats : * Canadian : ISO or month day year * Swiss : maybe "German style" with a dot * Belgian and French : dd mm yyyy but month place is not set on numerical date format (mm/dd/yyyy or dd/mm/yyyy). I see (french_France) the numerical value for month by using numerical date format on french DateHandler, maybe Canadian (Quebec) will rather use mm/dd/yyyy. Is that the problem ? I am trying numerical date format under my locale and see dd/{numerical month number}/yyyy. There is an exception by using calendars which return ISO date format. But you do not see numerical month value, isn't it ? Or it is something else ? Jérôme Brian Matherly a écrit : > Vlada, > >> It should also be noted that DateHandlers still rely on the >> presence >> of the correct locale on the system (namely, when >> formatting in the >> numerical format). > > I glad you brought this up. I noticed the same thing. I would be interested in your (and other people's) opinion on this. > > Should we manually program the number format for each language? > > One potential problem I can think of is that there may be different regions that use the same language, but different date formats. > > For example: > In the U.S. we speak English and typically use the date format mm/dd/yyyy. > In England, they speak English and typically use the date format dd/mm/yyyy. > > So the English DateHandler would be wrong for one of the two if we manually program it. > > Comments would be appreciated. > > ~Brian > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Jerome
::
Rate this Message:
Seems to me there is two classes on _DateDisplay.py :
class DateDisplay(object): class DateDisplayEn(DateDisplay): Localized DateHandler uses a part of the first one and ignore the second one, isn't it ? Maybe to have : -class DateDisplayEn(DateDisplay): +class DateDisplayUS(DateDisplay): +class DateDisplayUK(DateDisplay): Brian Matherly a écrit : >> I would have the date handlers set it. For those handlers >> that serve >> languages where both types are used, the date handler can >> check the >> local. That is, the english date handler should check the >> locale and >> use the numeric type defined there, whereas eg the dutch >> date handler >> can just take dd/mm/yyyy. >> >> So, an english person will have a locale that says >> dd/mm/yyyy and an >> american not. > > Ok, consider this: > > The English DateHandler will be used to generate reports in any language. That is, the user will be able to select the language at run-time. So, when a Dutch user is running Gramps in Dutch, and they choose to generate a report in English, how will the date look? The date format will depend on the language of the user, not the language of the report. > > ~Brian > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Jerome
::
Rate this Message:
Next time (45 message to read), I will start with the last message on
the post ... > Like this, somebody with en en_ZA (Zambia, no?) would use the default > english which would look at the installed locale, and hence use > dd/mm/yyyy, while on generation of reports, he can choose the en_GB or > en_US if he wants to. I remember testing available locales on my system on previous DateHandler versions. It was a script and places speaking english had often some specific issues (test results was not the same as en_UK or en_US). http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps22/test/dates.sh http://www.gramps-project.org/wiki/index.php?title=Date_Handler#Testing_with_command-line Benny Malengier a écrit : > 2009/11/6 Brian Matherly <brian@...>: >>>>> I would have the date handlers set it. For those >>> handlers >>>>> that serve >>>>> languages where both types are used, the date >>> handler can >>>>> check the >>>>> local. That is, the english date handler should >>> check the >>>>> locale and >>>>> use the numeric type defined there, whereas eg the >>> dutch >>>>> date handler >>>>> can just take dd/mm/yyyy. >>>>> >>>>> So, an english person will have a locale that >>> says >>>>> dd/mm/yyyy and an >>>>> american not. >>>> Ok, consider this: >>>> >>>> The English DateHandler will be used to generate >>> reports in any language. That is, the user will be able to >>> select the language at run-time. So, when a Dutch user is >>> running Gramps in Dutch, and they choose to generate a >>> report in English, how will the date look? The date format >>> will depend on the language of the user, not the language of >>> the report. >>> >>> As a Dutch speaker user, I would want things as dd/mm/yyyy, >>> even when >>> I generate US english. We don't like mm/dd/yyyy ! If I am >>> attentive >>> for any USA users of my website, then I choose the iso >>> date, or more >>> verbose months. >> I wonder if most people would agree with you. >> >> Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. >> >> Am I understanding correctly? > > No, what I say is that the datehandler should hard code it, but that > the default english date handler should have hard coded a lookup to > the installed locale, and use that. On the other hand, eg the dutch > datehandler has hardcoded dd/mm/yyyy. > In such a scheme, we can add a en_GB and a en_US datehandler that > inherit the default english datehandler, but don't look at the locale > for the numeric date, but have it hardcoded. > Like this, somebody with en en_ZA (Zambia, no?) would use the default > english which would look at the installed locale, and hence use > dd/mm/yyyy, while on generation of reports, he can choose the en_GB or > en_US if he wants to. > > Benny >> What do others think? >> >> I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. >> >> Maybe we should just force ISO dates for translated reports and not follow the user preferences. >> >> ~BM >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gramps-devel@... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Jerome
::
Rate this Message:
> Maybe we should just force ISO dates for translated reports and not follow the user preferences.
:-\ >:o :'( you are killing me ! > Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. only on numerical date format ! Note if I need to send a report to a native german, I need to set the date format according his culture. Users need to think on it ... This could be a nightmare if we do not know what is the local date format, but it is also nicer the send a report generated with his preferred date format. Maybe Benny said ISO date format to avoid this local date format search and Brian will use numerical because there is less error (two choices mm/dd/yyyy or dd/mm/yyyy). Both are right ! I suppose we could try to use both numerical date formats on user preferences. It is a display date issue, isn't it ? day = date_val[0] month = date_val[1] Is it not possible to "force/set" month place on numerical data format on alternate def _display_gregorian (DateDisplayEn) ? elif self.format == 1: if US: %m/%d/%Y % (month, day, year) if UK: %d/%m/%Y % (day, month, year) if en: ? ... class DateDisplay(object) uses : elif self.format == 1: if date_val[3]: return self.display_iso(date_val) else: if date_val[0] == date_val[1] == 0: value = str(date_val[2]) else: value = self._tformat.replace('%m', str(date_val[1])) value = value.replace('%d', str(date_val[0])) value = value.replace('%Y', str(abs(date_val[2]))) value = value.replace('-', '/') maybe also change on def _display_gregorian (DateDisplayFR) for Canadian Brian Matherly a écrit : >>>> I would have the date handlers set it. For those >> handlers >>>> that serve >>>> languages where both types are used, the date >> handler can >>>> check the >>>> local. That is, the english date handler should >> check the >>>> locale and >>>> use the numeric type defined there, whereas eg the >> dutch >>>> date handler >>>> can just take dd/mm/yyyy. >>>> >>>> So, an english person will have a locale that >> says >>>> dd/mm/yyyy and an >>>> american not. >>> Ok, consider this: >>> >>> The English DateHandler will be used to generate >> reports in any language. That is, the user will be able to >> select the language at run-time. So, when a Dutch user is >> running Gramps in Dutch, and they choose to generate a >> report in English, how will the date look? The date format >> will depend on the language of the user, not the language of >> the report. >> >> As a Dutch speaker user, I would want things as dd/mm/yyyy, >> even when >> I generate US english. We don't like mm/dd/yyyy ! If I am >> attentive >> for any USA users of my website, then I choose the iso >> date, or more >> verbose months. > > I wonder if most people would agree with you. > > Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. > > Am I understanding correctly? > > What do others think? > > I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. > > Maybe we should just force ISO dates for translated reports and not follow the user preferences. > > ~BM > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Benny Malengier
::
Rate this Message:
Jerome, no need to panic.
The piece of code is: try: tformat = time2fmt_map[timestr] except KeyError, e: tformat = '%d/%m/%Y' #default value and the DateDisplay has code: _tformat = GrampsLocale.tformat So, if you choose to print a report for an american relative, the numeric date format (if that is what you choose in the report) will be as in your locale, not as to what that person would expect it. My 'solution' is to have _tformat normally not coming from GrampsLocale, except for those languages that have users with both types. Those languages can have a default one using GrampsLocale, and then derived ones that set the _tformat hard coded. So eg, _Date_nl.py now uses _tformat from GrampsLocale, so that would change to: _tformat = %d/%m/%Y hard coded for in Dutch. Note that the official tformat for dutch is actually: %d-%m-%Y , which cannot be used as it conflicts with the ISO format. We never received complaints for that however, so I believe hard coding it for languages will also not be an issue. After all, we can make a _Date_nl.py and a _Date_nl_BE.py should some people really complain. Benny 2009/11/7 Jérôme <romjerome@...>: >> Maybe we should just force ISO dates for translated reports and not follow the user preferences. > > :-\ >:o :'( > > you are killing me ! > >> Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. > > only on numerical date format ! > > Note if I need to send a report to a native german, I need to set the > date format according his culture. Users need to think on it ... > This could be a nightmare if we do not know what is the local date > format, but it is also nicer the send a report generated with his > preferred date format. > > Maybe Benny said ISO date format to avoid this local date format search > and Brian will use numerical because there is less error (two choices > mm/dd/yyyy or dd/mm/yyyy). > > Both are right ! > > I suppose we could try to use both numerical date formats on user > preferences. It is a display date issue, isn't it ? > > day = date_val[0] > month = date_val[1] > > Is it not possible to "force/set" month place on numerical data format > on alternate def _display_gregorian (DateDisplayEn) ? > > elif self.format == 1: > if US: > %m/%d/%Y % (month, day, year) > if UK: > %d/%m/%Y % (day, month, year) > if en: > ? > ... > > class DateDisplay(object) uses : > > elif self.format == 1: > if date_val[3]: > return self.display_iso(date_val) > else: > if date_val[0] == date_val[1] == 0: > value = str(date_val[2]) > else: > value = self._tformat.replace('%m', str(date_val[1])) > value = value.replace('%d', str(date_val[0])) > value = value.replace('%Y', str(abs(date_val[2]))) > value = value.replace('-', '/') > > > maybe also change on def _display_gregorian (DateDisplayFR) for Canadian > > > Brian Matherly a écrit : >>>>> I would have the date handlers set it. For those >>> handlers >>>>> that serve >>>>> languages where both types are used, the date >>> handler can >>>>> check the >>>>> local. That is, the english date handler should >>> check the >>>>> locale and >>>>> use the numeric type defined there, whereas eg the >>> dutch >>>>> date handler >>>>> can just take dd/mm/yyyy. >>>>> >>>>> So, an english person will have a locale that >>> says >>>>> dd/mm/yyyy and an >>>>> american not. >>>> Ok, consider this: >>>> >>>> The English DateHandler will be used to generate >>> reports in any language. That is, the user will be able to >>> select the language at run-time. So, when a Dutch user is >>> running Gramps in Dutch, and they choose to generate a >>> report in English, how will the date look? The date format >>> will depend on the language of the user, not the language of >>> the report. >>> >>> As a Dutch speaker user, I would want things as dd/mm/yyyy, >>> even when >>> I generate US english. We don't like mm/dd/yyyy ! If I am >>> attentive >>> for any USA users of my website, then I choose the iso >>> date, or more >>> verbose months. >> >> I wonder if most people would agree with you. >> >> Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. >> >> Am I understanding correctly? >> >> What do others think? >> >> I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. >> >> Maybe we should just force ISO dates for translated reports and not follow the user preferences. >> >> ~BM >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gramps-devel@... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Jerome
::
Rate this Message:
> Jerome, no need to panic.
no problem ! ;) > My 'solution' is to have _tformat normally not coming from > GrampsLocale, except for those languages that have users with both > types. Those languages can have a default one using GrampsLocale, and > then derived ones that set the _tformat hard coded. +1 :) This map (time2fmt_map) was hidden on most localized date handler. It seems this code was able to return correct numerical month place on date format, but never used. Working with map is sometimes difficult for translators. > After all, we can make a _Date_nl.py and a _Date_nl_BE.py should some people really complain. do not know if we will split _Date_fr.py into fr_BE, fr_CA, fr_CH, fr_LU, fr_MO, fr_CD, fr_CG, fr_CI, fr_DZ, fr_GA, fr_GF, fr_GP, fr_MA, fr_MQ, fr_MU, fr_NC, fr_QC, fr_SN, fr_TG, fr_BR, etc ..., fr_FR Does it work on other OS (Windows ?) Benny Malengier a écrit : > Jerome, no need to panic. > > The piece of code is: > > try: > tformat = time2fmt_map[timestr] > except KeyError, e: > tformat = '%d/%m/%Y' #default value > > and the DateDisplay has code: > > _tformat = GrampsLocale.tformat > > So, if you choose to print a report for an american relative, the > numeric date format (if that is what you choose in the report) will be > as in your locale, not as to what that person would expect it. > > My 'solution' is to have _tformat normally not coming from > GrampsLocale, except for those languages that have users with both > types. Those languages can have a default one using GrampsLocale, and > then derived ones that set the _tformat hard coded. > > So eg, _Date_nl.py now uses _tformat from GrampsLocale, so that would > change to: > _tformat = %d/%m/%Y > hard coded for in Dutch. > > Note that the official tformat for dutch is actually: %d-%m-%Y , > which cannot be used as it conflicts with the ISO format. We never > received complaints for that however, so I believe hard coding it for > languages will also not be an issue. After all, we can make a > _Date_nl.py and a _Date_nl_BE.py should some people really complain. > > Benny > > 2009/11/7 Jérôme <romjerome@...>: >>> Maybe we should just force ISO dates for translated reports and not follow the user preferences. >> :-\ >:o :'( >> >> you are killing me ! >> >>> Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. >> only on numerical date format ! >> >> Note if I need to send a report to a native german, I need to set the >> date format according his culture. Users need to think on it ... >> This could be a nightmare if we do not know what is the local date >> format, but it is also nicer the send a report generated with his >> preferred date format. >> >> Maybe Benny said ISO date format to avoid this local date format search >> and Brian will use numerical because there is less error (two choices >> mm/dd/yyyy or dd/mm/yyyy). >> >> Both are right ! >> >> I suppose we could try to use both numerical date formats on user >> preferences. It is a display date issue, isn't it ? >> >> day = date_val[0] >> month = date_val[1] >> >> Is it not possible to "force/set" month place on numerical data format >> on alternate def _display_gregorian (DateDisplayEn) ? >> >> elif self.format == 1: >> if US: >> %m/%d/%Y % (month, day, year) >> if UK: >> %d/%m/%Y % (day, month, year) >> if en: >> ? >> ... >> >> class DateDisplay(object) uses : >> >> elif self.format == 1: >> if date_val[3]: >> return self.display_iso(date_val) >> else: >> if date_val[0] == date_val[1] == 0: >> value = str(date_val[2]) >> else: >> value = self._tformat.replace('%m', str(date_val[1])) >> value = value.replace('%d', str(date_val[0])) >> value = value.replace('%Y', str(abs(date_val[2]))) >> value = value.replace('-', '/') >> >> >> maybe also change on def _display_gregorian (DateDisplayFR) for Canadian >> >> >> Brian Matherly a écrit : >>>>>> I would have the date handlers set it. For those >>>> handlers >>>>>> that serve >>>>>> languages where both types are used, the date >>>> handler can >>>>>> check the >>>>>> local. That is, the english date handler should >>>> check the >>>>>> locale and >>>>>> use the numeric type defined there, whereas eg the >>>> dutch >>>>>> date handler >>>>>> can just take dd/mm/yyyy. >>>>>> >>>>>> So, an english person will have a locale that >>>> says >>>>>> dd/mm/yyyy and an >>>>>> american not. >>>>> Ok, consider this: >>>>> >>>>> The English DateHandler will be used to generate >>>> reports in any language. That is, the user will be able to >>>> select the language at run-time. So, when a Dutch user is >>>> running Gramps in Dutch, and they choose to generate a >>>> report in English, how will the date look? The date format >>>> will depend on the language of the user, not the language of >>>> the report. >>>> >>>> As a Dutch speaker user, I would want things as dd/mm/yyyy, >>>> even when >>>> I generate US english. We don't like mm/dd/yyyy ! If I am >>>> attentive >>>> for any USA users of my website, then I choose the iso >>>> date, or more >>>> verbose months. >>> I wonder if most people would agree with you. >>> >>> Assuming that your suggestion is the best way to go, each DateHandler would have to format the date according to the GrampsLocale, and not necessarily in conformance to the language the report is being generated in. So the DateHandler should not custom format the date for each language. >>> >>> Am I understanding correctly? >>> >>> What do others think? >>> >>> I only speak one language. So my motivation to generate a report in a different language would be to send it to someone who speaks that language. As such, I would want the translated report to be in a format that most closely matches that of my target reader - regardless of how I like dates to be formatted. So, I guess I disagree with you and would prefer each DateHandler specify it's own date format (hard coded) and not use the locale for date formatting. >>> >>> Maybe we should just force ISO dates for translated reports and not follow the user preferences. >>> >>> ~BM >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>> trial. Simplify your report design, integration and deployment - and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gramps-devel@... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gramps-devel@... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Benny Malengier
::
Rate this Message:
2009/11/7 Jérôme <romjerome@...>:
>> Jerome, no need to panic. > > no problem ! ;) > >> My 'solution' is to have _tformat normally not coming from >> GrampsLocale, except for those languages that have users with both >> types. Those languages can have a default one using GrampsLocale, and >> then derived ones that set the _tformat hard coded. > > +1 :) > > This map (time2fmt_map) was hidden on most localized date handler. > It seems this code was able to return correct numerical month place on date > format, but never used. > > Working with map is sometimes difficult for translators. > >> After all, we can make a _Date_nl.py and a _Date_nl_BE.py should some >> people really complain. > > do not know if we will split _Date_fr.py into fr_BE, fr_CA, fr_CH, fr_LU, > fr_MO, fr_CD, fr_CG, fr_CI, fr_DZ, fr_GA, fr_GF, fr_GP, fr_MA, fr_MQ, fr_MU, > fr_NC, fr_QC, fr_SN, fr_TG, fr_BR, etc ..., fr_FR First, these can be present in the same plugin, no need for new python files. Second, above looks like overkill. For most languages, the language is tied to one single country, so there really should not be too much problem. Only english, spanish, french and perhaps some others really need to make a subdistinction as to date format. Benny > Does it work on other OS (Windows ?) > > > > Benny Malengier a écrit : >> >> Jerome, no need to panic. >> >> The piece of code is: >> >> try: >> tformat = time2fmt_map[timestr] >> except KeyError, e: >> tformat = '%d/%m/%Y' #default value >> >> and the DateDisplay has code: >> >> _tformat = GrampsLocale.tformat >> >> So, if you choose to print a report for an american relative, the >> numeric date format (if that is what you choose in the report) will be >> as in your locale, not as to what that person would expect it. >> >> My 'solution' is to have _tformat normally not coming from >> GrampsLocale, except for those languages that have users with both >> types. Those languages can have a default one using GrampsLocale, and >> then derived ones that set the _tformat hard coded. >> >> So eg, _Date_nl.py now uses _tformat from GrampsLocale, so that would >> change to: >> _tformat = %d/%m/%Y >> hard coded for in Dutch. >> >> Note that the official tformat for dutch is actually: %d-%m-%Y , >> which cannot be used as it conflicts with the ISO format. We never >> received complaints for that however, so I believe hard coding it for >> languages will also not be an issue. After all, we can make a >> _Date_nl.py and a _Date_nl_BE.py should some people really complain. >> >> Benny >> >> 2009/11/7 Jérôme <romjerome@...>: >>>> >>>> Maybe we should just force ISO dates for translated reports and not >>>> follow the user preferences. >>> >>> :-\ >:o :'( >>> >>> you are killing me ! >>> >>>> Assuming that your suggestion is the best way to go, each DateHandler >>>> would have to format the date according to the GrampsLocale, and not >>>> necessarily in conformance to the language the report is being generated in. >>>> So the DateHandler should not custom format the date for each language. >>> >>> only on numerical date format ! >>> >>> Note if I need to send a report to a native german, I need to set the >>> date format according his culture. Users need to think on it ... >>> This could be a nightmare if we do not know what is the local date >>> format, but it is also nicer the send a report generated with his >>> preferred date format. >>> >>> Maybe Benny said ISO date format to avoid this local date format search >>> and Brian will use numerical because there is less error (two choices >>> mm/dd/yyyy or dd/mm/yyyy). >>> >>> Both are right ! >>> >>> I suppose we could try to use both numerical date formats on user >>> preferences. It is a display date issue, isn't it ? >>> >>> day = date_val[0] >>> month = date_val[1] >>> >>> Is it not possible to "force/set" month place on numerical data format >>> on alternate def _display_gregorian (DateDisplayEn) ? >>> >>> elif self.format == 1: >>> if US: >>> %m/%d/%Y % (month, day, year) >>> if UK: >>> %d/%m/%Y % (day, month, year) >>> if en: >>> ? >>> ... >>> >>> class DateDisplay(object) uses : >>> >>> elif self.format == 1: >>> if date_val[3]: >>> return self.display_iso(date_val) >>> else: >>> if date_val[0] == date_val[1] == 0: >>> value = str(date_val[2]) >>> else: >>> value = self._tformat.replace('%m', str(date_val[1])) >>> value = value.replace('%d', str(date_val[0])) >>> value = value.replace('%Y', str(abs(date_val[2]))) >>> value = value.replace('-', '/') >>> >>> >>> maybe also change on def _display_gregorian (DateDisplayFR) for Canadian >>> >>> >>> Brian Matherly a écrit : >>>>>>> >>>>>>> I would have the date handlers set it. For those >>>>> >>>>> handlers >>>>>>> >>>>>>> that serve >>>>>>> languages where both types are used, the date >>>>> >>>>> handler can >>>>>>> >>>>>>> check the >>>>>>> local. That is, the english date handler should >>>>> >>>>> check the >>>>>>> >>>>>>> locale and >>>>>>> use the numeric type defined there, whereas eg the >>>>> >>>>> dutch >>>>>>> >>>>>>> date handler >>>>>>> can just take dd/mm/yyyy. >>>>>>> >>>>>>> So, an english person will have a locale that >>>>> >>>>> says >>>>>>> >>>>>>> dd/mm/yyyy and an >>>>>>> american not. >>>>>> >>>>>> Ok, consider this: >>>>>> >>>>>> The English DateHandler will be used to generate >>>>> >>>>> reports in any language. That is, the user will be able to >>>>> select the language at run-time. So, when a Dutch user is >>>>> running Gramps in Dutch, and they choose to generate a >>>>> report in English, how will the date look? The date format >>>>> will depend on the language of the user, not the language of >>>>> the report. >>>>> >>>>> As a Dutch speaker user, I would want things as dd/mm/yyyy, >>>>> even when >>>>> I generate US english. We don't like mm/dd/yyyy ! If I am >>>>> attentive >>>>> for any USA users of my website, then I choose the iso >>>>> date, or more >>>>> verbose months. >>>> >>>> I wonder if most people would agree with you. >>>> >>>> Assuming that your suggestion is the best way to go, each DateHandler >>>> would have to format the date according to the GrampsLocale, and not >>>> necessarily in conformance to the language the report is being generated in. >>>> So the DateHandler should not custom format the date for each language. >>>> >>>> Am I understanding correctly? >>>> >>>> What do others think? >>>> >>>> I only speak one language. So my motivation to generate a report in a >>>> different language would be to send it to someone who speaks that language. >>>> As such, I would want the translated report to be in a format that most >>>> closely matches that of my target reader - regardless of how I like dates to >>>> be formatted. So, I guess I disagree with you and would prefer each >>>> DateHandler specify it's own date format (hard coded) and not use the locale >>>> for date formatting. >>>> >>>> Maybe we should just force ISO dates for translated reports and not >>>> follow the user preferences. >>>> >>>> ~BM >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gramps-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gramps-devel@... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Re: Serbian DateHandler update
by Vlada Peric
::
Rate this Message:
On Sat, Nov 7, 2009 at 12:25 PM, Benny Malengier <benny.malengier@...> wrote: Of course, there isn't any real reason not to allow the user to actually define their own format (using the elements we currently provide: short/long month names, roman numerals, numbers with whatever separators the user wishes), except that it might be too much work for too little gain. GRAMPS would still have to provide a sensible default for each language (else how would Brian know how to format dates in Serbian, even if he had the translated month names at his disposal). Thoughts? Jerome, no need to panic. That bit of code is the core of my problem. It means that the following code: value = self._tformat.replace('%m', str(date_val[1])) value = value.replace('%d', str(date_val[0])) value = value.replace('%Y', str(abs(date_val[2]))) value = value.replace('-', '/') will behave differently based on whether the sr_RS locale (or any other) is installed or not. This code is used by most of the DateHandlers to display dates in the "numerical" format, as that's what the english displayer uses. If we systematically change this particular bit of code to actually print an appropriate format regardless of the presence of the correct locale, I wouldn't have any other complaints with the current system. [one minor quibble is that the family trees dialogue that opens when GRAMPS starts doesn't use the DateHandler, but rather a system function, but it's really not that important] -- Vlada Perić ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gramps-devel mailing list Gramps-devel@... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
| Free embeddable forum powered by Nabble | Forum Help |
