Re: Cities.dat corrections

Am Dienstag 15 September 2009 09:40:52 schrieb Burkhard Lück:
> Am Dienstag 15 September 2009 09:21:00 schrieb Akarsh Simha:
> > I believe we have a consensus on H. List and Fu"rth. If I'm right
> > here, I could go ahead and remove those two lines if you wish and
> > replace the data with appropriate data for Fu"rth if you wish.
> 
> Yes, please do so.
> 
Translating kstars today I found the two outdated/wrong german cities H. List 
and Fu"rth, so I fixed their data.

--

-- 
Burkhard Lück

KDE/kdeedu/kstars/kstars/skyobjects

SVN commit 1032026 by asimha:

Fixing a bug with the calculation of illuminated fraction of the
moon. The Phase was stored in degrees, but was multiplied by 180 / PI
instead of PI / 180 while converting it into radians!

BUG: 209646
CCMAIL: kstars-devel <at> kde.org

 M  +2 -2      ksmoon.cpp  
 M  +1 -1      ksmoon.h  

--- trunk/KDE/kdeedu/kstars/kstars/skyobjects/ksmoon.cpp #1032025:1032026
@@ -231,8 +231,8 @@
 }

 void KSMoon::findPhase() {
-    KSSun *Sun = (KSSun*)KStarsData::Instance()->skyComposite()->findByName( "Sun" ); // TODO: Get rid
of this ugly thing by making KSSun singleton.
-    Phase = ecLong()->Degrees() - Sun->ecLong()->Degrees();
+    KSSun *Sun = (KSSun*)KStarsData::Instance()->skyComposite()->findByName( "Sun" );
+    Phase = ecLong()->Degrees() - Sun->ecLong()->Degrees(); // Phase is obviously in degrees
     double DegPhase = dms( Phase ).reduce().Degrees();
     int iPhase = int( 0.1*DegPhase+0.5 ) % 36; // iPhase must be in [0,36) range
     QString imName = QString().sprintf("moon%02d.png", iPhase);
--- trunk/KDE/kdeedu/kstars/kstars/skyobjects/ksmoon.h #1032025:1032026
@@ -55,7 +55,7 @@

     /** <at> return the illuminated fraction of the Moon as seen from Earth
     	*/

branches/KDE/4.3/kdeedu/kstars/kstars/skyobjects

SVN commit 1032036 by asimha:

Backporting fix to bug #209646

CCMAIL: kstars-devel <at> kde.org
CCBUG: 209646

 M  +2 -2      ksmoon.cpp  
 M  +1 -1      ksmoon.h  

--- branches/KDE/4.3/kdeedu/kstars/kstars/skyobjects/ksmoon.cpp #1032035:1032036
@@ -220,8 +220,8 @@
 }

 void KSMoon::findPhase() {
-    KSSun *Sun = (KSSun*)KStarsData::Instance()->skyComposite()->findByName( "Sun" ); // TODO: Get rid
of this ugly thing by making KSSun singleton.
-    Phase = ecLong()->Degrees() - Sun->ecLong()->Degrees();
+    KSSun *Sun = (KSSun*)KStarsData::Instance()->skyComposite()->findByName( "Sun" );
+    Phase = ecLong()->Degrees() - Sun->ecLong()->Degrees(); // Phase is obviously in degrees
     double DegPhase = dms( Phase ).reduce().Degrees();
     int iPhase = int( 0.1*DegPhase+0.5 );
     if (iPhase==36) iPhase = 0;
--- branches/KDE/4.3/kdeedu/kstars/kstars/skyobjects/ksmoon.h #1032035:1032036
@@ -54,7 +54,7 @@

     /** <at> return the illuminated fraction of the Moon as seen from Earth
     	*/
-    double illum( void ) const { return 0.5*(1.0 - cos( Phase * 180.0 / dms::PI ) ); }
+    double illum( void ) const { return 0.5*(1.0 - cos( Phase * dms::PI / 180.0 ) ); }

Wrong / misspelled data in Cities.dat

Hi,

translating the kstars catalog I noticed some wrong / misspelled data:

1) Bucarest :  : Romania : 44 : 24 :  8 : N :  25 :  6 : 45 : E :  2.0 : EU
2) Bucharest :  : Romania : 44 : 22 : 59 : N :  26 : 10 :  0 : E : 2.0  : EU

44 : 24 :  8 / 25 :  6 : 45 is 50 miles west of the center of Bucharest

The center of Bucharest has 44° 25′ 57″ N, 26° 6′ 14″ E

Remove 1) and change 2) to 44° 25′ 57″ N, 26° 6′ 14″ E?

2) Loire atlantique / Loire-atlantique and Seine maritime / Seine-maritime
fr.wikipedia.org/ spells these names Loire-Atlantique + Seine-Maritime

3) Tanzania / Tanzanie 
should be spelled Tanzania as in all other kde catalogs.

4) Zambia / Zambie
should be spelled Zambia as in all other kde catalogs

--

-- 
Burkhard Lück
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel

Re: KDE/kdeedu/kstars/kstars/tools

Am Freitag 09 Oktober 2009 22:30:50 schrieb Prakash Mohan:
> SVN commit 1033270 by prakash:
> 
> Adding a silly 0 as the 'missing' argument for i18np to make it stop shoing
>  the ugly (i18n_PLURAL_ARGUMENT_MISSING) error.
> 
> CCMAIL: kstars-devel <at> kde.org
> 
> 
>  M  +1 -1      wutdialog.cpp
> 
> 
> --- trunk/KDE/kdeedu/kstars/kstars/tools/wutdialog.cpp #1033269:1033270
> @@ -172,7 +172,7 @@
> 
>      WUT->SunSetLabel->setText( i18nc( "Sunset at time %1 on date %2",
>  "Sunset: %1 on %2" , sSet, KGlobal::locale()->formatDate( Evening.date(),
>  KLocale::LongDate) ) ); WUT->SunRiseLabel->setText( i18nc( "Sunrise at
>  time %1 on date %2", "Sunrise: %1 on %2" , sRise,
>  KGlobal::locale()->formatDate( Tomorrow.date(), KLocale::LongDate) ) ); - 
>    WUT->NightDurationLabel->setText( i18np("Night duration: %1 hour",
>  "Night duration: %1 hours", sDuration ) ); +   
>  WUT->NightDurationLabel->setText( i18np("Night duration: %1 hour", "Night
>  duration: %1 hours", sDuration, 0 ) );
> 
>      // moon almanac information
>      KSMoon *oMoon = reinterpret_cast<KSMoon*>( data->objectNamed("Moon")
>  ); _______________________________________________
> Kstars-devel mailing list
> Kstars-devel <at> kde.org

Re: KDE/kdeedu/kstars/kstars/tools

> From a translators pov this seems to be a strange usage of i18np. How should
> this be translated properly?
>
> Can you please explain?
> Please give an example of a singular and plural string.

I think there seems to a mistake in the i18np call here. IIUC we're
supposed to check for the number of hours as a 'number' and not a
'string'. Will that help running the translations smoothly?
--

-- 
Prakash
Undergraduate Student
Department of Aerospace Engineering
Indian Institute Of Technology Madras

Re: KDE/kdeedu/kstars/kstars/tools

Am Samstag 10 Oktober 2009 16:19:41 schrieb Prakash Mohan:
> > From a translators pov this seems to be a strange usage of i18np. How
> > should this be translated properly?
> >
> > Can you please explain?
> > Please give an example of a singular and plural string.
> 
> I think there seems to a mistake in the i18np call here. IIUC we're
> supposed to check for the number of hours as a 'number' and not a
> 'string'. Will that help running the translations smoothly?
> 

Afaik there are 5 different states in this string, list them here with the 
german wording translated literally to english:

1) Night Duration: <=00:00 
"Object does not set" or "No set" or "Always above horizon"

2) Night Duration: 00:yy with 01 < yy < 60
"yy minutes"

3) Night Duration: 01:yy
"01 hour 01 minute" + "01 hour yy minutes"
(singular/singular + singular/plural)

4) Night Duration: xx:yy with xx > 1
"xx hours 01 minute" + "xx hours yy minutes"
(plural/singular + plural/plural)

5) Night Duration: >= 24:00

Kstars

I see that Kstars will not resume an add-on download. Is there any other way to get this data? I could use wget
to resume. I'm a dial-up and don't think I'll ever be able to download that 1.4 gigabyte add-on (USNO NOMAD
Catalog), bummer, because I really like Kstars. Great job! One other thing, The international space
station is crossing the sky all the time, could you add a tracking feature for the station? I'd really like
to see it in the sky. Thank you.

Re: Followup: Cities.dat patch, commit 951200

> > Merging Patrick Levesque's patch adding a few cities from France and
> > Canada and fixing timezones of some Hungarian cities.
> 
> There seems to have been a problem with the patch; the current SVN
> checkout does not match the patch I sent; it appears the character
> encoding was mangled somehow; the current Cities.dat file from SVN is
> not well-formed UTF-8 anymore.
> 
> Here is a patch to revision 951201 from a few minutes ago, that seems to
> fix *everything* :)
> 
> I bzipped2 the file to remove at least one transit where character
> encoding might be b0rked.

Hi Patrick,

I'm sorry, but this thing slipped totally out of my notice. Is this
still relevant?

My apologies.

Regards
Akarsh

Re: Followup: Cities.dat patch, commit 951200

>> There seems to have been a problem with the patch; the current SVN
>> checkout does not match the patch I sent; it appears the character
>> encoding was mangled somehow; the current Cities.dat file from SVN is
>> not well-formed UTF-8 anymore.
> I'm sorry, but this thing slipped totally out of my notice. Is this
> still relevant?

The current checkout is well-formed UTF-8; you can thus ignore the
bugfix.

--

-- 
 --====|====--
    --------================|================--------
        Patrice Levesque
         http://ptaff.ca/
        kstars.wayne <at> ptaff.ca
    --------================|================--------
 --====|====--
--

_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel