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

[Loïc Martin]

David Bruce wrote:
> 2009/2/7 Loïc Martin <loic.martin3 at gmail.com>:
>> 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.

There's maybe no easy solution. I'm just afraid I won't notice the 
translation has to be updated ;)

>> 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.

That's probably why I can't find any watch file or get-orig-source 
target in debian/rules, since it would probably be a pain to write with 
that system. Maybe Holger Levsen has a better idea, but would it be 
possible to also link to the font-less tarball in the download page, or 
in a public place? Actually, the latest Debian source package 
(1.5.17.dfsg1-4) still has the fonts, even though they aren't used even
in data-nonfree.

Being able to get a font-less tarball with uscan might
make things simpler and remove the "need" for the fonts in the source
package (still 1.8MB). Even better if it comes without the .gmo (don't 
quote me on that, but even though I'm still novice about translation, 
none of the source packages I've looked at provide .mo files).

>> - 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.

I understand, especially for Windows/OSX. I'll have a look how Holger 
does it for the Debian 1.7.3+ package,  but it might be similar to the 
font situation - it might not be necessary to include those files in the 
tarball for packagers (recreating them at package creation time is 
better, since one only has to patch the .po files when there's something 
to fix).

>> - 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.

I was surprised, so I looked into tuxmath Ubuntu package (Jaunty 
version). The only .svg is in /data/images/igloos/composite.svg, and I 
don't think it's used (even though I couldn't manage to run the game in 
higher resolution than the default one, the option --fullscreen doesn't 
use a higher resolution).

The package in Jaunty uses a png icon (I looked at the desktop file in 
debian/), and it's synced straight from Debian (which is funny, since 
tuxtype is merge, possibly because they add an Ubuntu line in the 
desktop file - I'll try to find about it when Debian has a more recent 
version and it's time to merge/sync). There's still the possibility some 
changes in Ubuntu didn't end up back in Debian, and the sync with Debian 
for Jaunty dropped the changes in an earlier release for Ubuntu.

I couldn't find the .svg icon in the latest source tarball for tuxmath 
either (1.7.1).

>> 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.

I'll have a look what I can come up with. The best solution when using 
bitmaps should be to export them at the highest resolution possible 
(25XX or at least 1920x1200) then scale down, instead of the reverse.

Loïc