[Tux4kids-tuxtype-dev] Corrected French .po file + .desktop file translation for Tux Typing

[David Bruce]

Hi Loïc,

2009/2/7 Loïc Martin <loic.martin3 at gmail.com>:
> Hi,
>
> The French translation of Tux Typing had incomplete translation, inaccurate
> strings and about all accented letters missing. Two strings were translated
> in the .po file, but didn't make it to the .mo file (either the one in the
> tarball or after using msgfmt ) - fixed in the attached file.
>
> I also added French translation to the .desktop file, and took the liberty
> to change the displayed name from TuxType to Tux Typing, since it's the name
> used on the web site.

Thanks, I'll put them in.

> I'd like to follow the French translation, but I'm already subscribed to
>  far more mailing lists than I could follow ;). Is there a way to be pinged
> of string changes short of remembering to check the site often or reading
> the mailing list without a fail?

I don't know.  I'm even less likely to remember to email you whenever
a string changes ;).  Maybe we could have some sort of convention for
announcing string changes with a particular keyword in the subject
line that translators could set their mail to filter on.

>
> A few questions:
> - in the release announcement for 1.7.3 there was mention of an archive
> without the fonts - I can't manage to find it at
> http://alioth.debian.org/frs/?group_id=31080 ;

The archive without fonts is only accessible if you are logged in to
Alioth.  It is really only intended for making Debian packages,
because Debian disallows bundled fonts.  Right now, tuxtype has no
ability to use system fonts sanely.  It looks for the fonts either in
the bundled font path, or in the hard-coded Debian location for the
exact font requested.  Until very recently, it would segfault if it
failed to find a font, but now at least it tries to fall back to the
default Andika font.  Better font handling might be a good GSoC
project.

> - is there any reason for the tarball to contain .gmo files since they're
> created from the .po files (and do the configure/make process included
> creates them)?

The tarball needs to have the .gmo files because they are generated by
msgfmt (part of gettext utilities) which is not required for
installation.  msgfmt is run during a "make dist", but not in "make"
or "make install".  The idea is that someone doing a "./configure;
make; sudo make install" should not need specialized tools like
autoconf, automake, or the gettext utilities.

> - is the tuxtype.ico file only used for Windows (or OSX, I'm no expert), or
> is it used for anything on *nix?
> - is it possible to include either a 32x32 .xmp icon, a 42x42 .png
> (preferably the latter, unless Holger objects), or even better an .svg?

I'm not too sure, either - been meaning to look into this.  I checked
into the OSX situation recently - it uses a *.icns file, which is
really three bitmaps (128x128, 64x64, and 32x32) in a single file.  I
was surprised, as I assumed OSX used svg for its scalable icons.

The Ubuntu version of tuxmath that came on my daughter's Dell has an
attractive svg icon for tuxmath that is used by the customized Gnome
interface.  I added the icon to our svn a couple of days ago, but so
far our upstream build doesn't do anything with it.

So yes, we need to go over all the icon issues and make them more presentable.

>
> There was also talk about an .svg transition. I'd be happy to have a go at
> drawing the .svg, but I'd appreciate to know how far in the future the code
> will be able to support it.

So far, it's only talk.  It might be a GSoC project for this summer.

> Also, in the meantime, would it be possible to
> use higher resolution bitmaps (in which case I could draw the .svg but
> export them to bitmap graphics and still be able to see the improvements ;)
> ) since tuxtype now support displaying to a monitor's native resolution?

Yes, I think we could do that.  We then might need to scale the images
down however if running at 640x480.

Cheers,

David Bruce