tuxpaint-i18n — Discussion on internationalization and translation of Tux Paint

Re: [Tuxpaint-i18n] Lots of new Magic tools coming to 0.9.34!

[Bill K. <nb...@so...>]

On Tue, Oct 08, 2024 at 12:09:37AM +0200, Pere Pujal i Carabantes wrote:
> Hi Bill, and all,
> 
> I started the Catalan update and noticed that translations for Fractal strings don't show up.

Yes, I was getting a bit complicated with the string
construction, and everything being returned as the "tool tip"
(description) was being wrapped in `gettext_noop()` instead
of `gettext()`.

This _normally_ works alright, surprisingly, because the
text rendering routine inside Tux Paint does its own call
to `gettext()` around the string it receives.  But in this
case, it's a _constructed_ string, made out of the various
`sprintf()`'d string ("%s") parts, so by the time it gets
in there, the gettext routines don't recognize it.

I'm correcting that, and also making sure that all of the
magic tools _only_ use `gettext_noop()` when wrapping a
string inside an array, e.g.

  char * my_descriptions[NUM_TOOLS] = {
    gettext_noop("I am tool #1"),
    gettext_noop("I am tool #2"),
  };

And then when we return the string back to Tux Paint,
making sure `gettext()` (and NOT `gettext_noop()`) is
always used, e.g.:

  return strdup(gettext(my_descriptions[which]));

This makes me worry that behavior might change, but it's
apparently been pretty messy and inconsistent all this
time anyway. :-/  So it's _probably_ fine...?

Please let me know if you notice any more oddness, though!

-bill!
PS - After playing with Sprials and Square Spirals, I'm
going to try and make two more tools which are variants:
Concentric Circles and Concentric Squares.  Sorry for more
strings! ;-)

Re: [Tuxpaint-i18n] Lots of new Magic tools coming to 0.9.34!

[Pere P. i C. <per...@gm...>]

Hi Bill, and all,

I started the Catalan update and noticed that translations for Fractal strings don't show up.

HTH
Pere


El dg. 29 de 09 de 2024 a les 00:05 -0700, en/na Bill Kendrick va escriure:
> Hi translator friends!  I've been very busy adding
> a bunch more silly magic tools to Tux Paint, and am
> starting to get the itch to make a new release soon. :)
> 
> So if you haven't in a while, please fetch the latest POT
> and PO files, and send your updates my way if you have time!
> 
> Thanks and happy fall (N) or spring (S) ;-)
> 
> -bill!
> 
> 
> 
> _______________________________________________
> Tuxpaint-i18n mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-i18n

Re: [Tuxpaint-i18n] Lots of new Magic tools coming to 0.9.34!

[Bill K. <nb...@so...>]

On Sun, Sep 29, 2024 at 12:05:46AM -0700, Bill Kendrick wrote:
> Hi translator friends!  I've been very busy adding
> a bunch more silly magic tools to Tux Paint, and am
> starting to get the itch to make a new release soon. :)
> 
> So if you haven't in a while, please fetch the latest POT
> and PO files, and send your updates my way if you have time!

I'm sorry!  I can't help myself!  I added three more Magic
tools since Sunday (Spraypaint, Spiral, and Square Spiral).

I'll try and stop myself from adding more, until after
we've released Tux Paint 0.9.34. :-)  I'll try and get that
process started, and focus on fixing any bugs or making
functionality tweaks... things that should hopefully not
affect any strings.

Thanks again,

-bill!

[Tuxpaint-i18n] Lots of new Magic tools coming to 0.9.34!

[Bill K. <nb...@so...>]

Hi translator friends!  I've been very busy adding
a bunch more silly magic tools to Tux Paint, and am
starting to get the itch to make a new release soon. :)

So if you haven't in a while, please fetch the latest POT
and PO files, and send your updates my way if you have time!

Thanks and happy fall (N) or spring (S) ;-)

-bill!

Re: [Tuxpaint-i18n] Please submit translations for Tux Paint 0.9.33

[Pere P. i C. <per...@gm...>]

Hi everybody,

Just want to stat that Karl and Bill have made a great improvement for 
fitting long words in small buttons,
see https://sourceforge.net/p/tuxpaint/bugs/288/ 
and evaluate if your language could benefit of soft hyphens.

Many thanks
Pere



El dc. 29 de 05 de 2024 a les 00:10 -0700, en/na Bill Kendrick va escriure:
> I'm hoping to release Tux Paint 0.9.33 in the coming weeks.
> The major new features include:
> 
>  * Transparent erasers
>  * Filled polygon drawing magic tool
>  * Dithered pixel magic tools
>  * Variations of the "3D Glasses" magic tool
>  * Ability to ungroup Magic tools (make it one big list)
>  * Brush descriptions
> 
> Srings have changed or been added to the various parts of the project
> (not just `tuxpaint`, but also `tuxpaint-config` and `tuxpaint-docs`,
> of course; also the website, of course).
> 
> If you'd like to get translation updates included in 0.9.33, please
> commit them to the Git repositories at SourceForge if you have
> access, or if you've cloned the project, commit to your own repo
> and make a Pull Request.  Or, of course, you can just email me your
> PO file(s) and I can commit them on your behalf.
> 
> As usual, see https://tuxpaint.org/help/po/ for details as well.
> 
> Thanks in advance!  I hope everyone is staying well!
> 
> -bill!
> 
> 
> _______________________________________________
> Tuxpaint-i18n mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-i18n

[Tuxpaint-i18n] Fwd: [Tuxpaint-stamps] Reduced bitrate of many stamp description sounds

[Karl O. H. <ka...@hu...>]

[Forgot to CC the tuxpaint-i18n list.]

─────── Vidaresend melding ───────
Emne: 	Re: [Tuxpaint-stamps] [Tuxpaint-i18n] Reduced bitrate of many 
stamp description sounds
Dato: 	Sun, 2 Jun 2024 20:11:58 +0200
Frå: 	Karl Ove Hufthammer <ka...@hu...>
Til: 	tux...@li...



Bill Kendrick skreiv 02.06.2024 19:33:
>>> The other day I went through and converted all descriptive sound files
>>> in Tux Paint Stamps -- the sounds of people speaking the names of
>>> stamps -- from stereo to mono.  That saved almost 100MB of space
>>> used by those OGG files!
>> I think this is misguided. Ogg Vorbis uses channel coupling (similar to
>> joint stereo in the MP3 format), and since the recordings have been done by
>> (mono) microphones, converting from stereo to mono should in theory have
>> *no* effect.
> There were many recordings where the audio was only playing in one
> channel (e.g., if I had headphones on, I'd only hear the voice speaking
> the stamp description in my left ear, and silence on my right).

OK, I see. That would certainly be a reason to convert to mono. But when 
doing this, wouldn’t the software mix 50% sound with 50% silence, 
effectively halving the volume level? So you should normalize the volume 
afterwards.

Also note that there is *possibly* a difference in the audio output 
between a mono sound file and a stereo sound file with identical left 
and right channels. On a surround (5.1) system, PulseAudio/PipeWire by 
default (I think) plays mono sound through the centre speaker, but 
stereo sound through the left and the right front speakers. At least, 
this is what happens when you play the file through a simple audio 
player, e.g., mpv. But if libsdl does some mixing internally and only 
outputs stereo audio, this will not happen.

>      Original → Encode to Ogg → Reencode (mono) → Reencode (bitrate)
>
> Seehttps://wiki.hydrogenaud.io/index.php?title=Transcoding
>
> It would be much better to encode to the final format from the *original*
> uncompressed files (if you have them).
> Oof, yes, I would have to dig them back up from an earlier release
> I suppose.

They should all be in the Git history. Example:

git log --name-only 92d3d3236 | grep wav$

But I agree that digging them up, checking for any later updates 
(including renames) etc. would be a lot of work …

BTW, perhaps we could have a separate repository where we could store 
all the original (.wav or .flac) files, and *automatically* generate the 
.ogg (or .opus or whatever) files from these? Then it would be easier to 
do *future* updates, e.g., to reencode when a new and better format 
comes along, to downmix to mono, to normalize the sound level etc.

> So what do you think, should I open some tickets for these things?
> e.g.:
>
>   1. restore original sound files from pre-12/2024 and
>      do a smarter job at compressing them, doing all of this
>      at once (rather than lossily one step at a time):
>
>      a. stereo->mono the truly bad stereo (sound in one channel,
>         silence in the other) recordings
>
>      b. reduce the quality level
>
>   2. investigate use of the Opus codec
>
>      a. ensure it's usable on all major platforms
>         (I assume Windows, Linux, macOS, and Android are good;
>         Haiku would be the main question)
>
>      b. using the files as they existed after step 1a,
>         re-encode using Opus codec; assuming the file size
>         is better (smaller) over all, use it

There’s no rush *doing* all of this, but having open tickets could be 
nice, so that we don’t lose track.


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-i18n] [Tuxpaint-stamps] Reduced bitrate of many stamp description sounds

[Bill K. <nb...@so...>]

On Sun, Jun 02, 2024 at 10:33:50AM -0700, Bill Kendrick wrote:
<snip>
> I admit, a lot of the localized sound samples we have were done
> by children in noisy environments and the quality of the recordings
> were very bad to begin with.  I cast a wide net when I decided to
> try and shrink the filesize of the sound files.  We have nearly 17,000
> of them in tuxpaint-stamps
<snip>

Oops, I ran `find` from the top level, so it included my `build/`
subdir and doubled the number.  I was also counting ALL `.ogg` files,
not just the description ones.  That said, there are still ~8,000! :-D

-bill!

Re: [Tuxpaint-i18n] [Tuxpaint-stamps] Reduced bitrate of many stamp description sounds

[Bill K. <nb...@so...>]

On Sun, Jun 02, 2024 at 02:45:54PM +0200, Karl Ove Hufthammer wrote:
> [Sorry for the late reply to this.]
> 
> Bill Kendrick skreiv 12.01.2024 06:05:
> > The other day I went through and converted all descriptive sound files
> > in Tux Paint Stamps -- the sounds of people speaking the names of
> > stamps -- from stereo to mono.  That saved almost 100MB of space
> > used by those OGG files!
> 
> I think this is misguided. Ogg Vorbis uses channel coupling (similar to
> joint stereo in the MP3 format), and since the recordings have been done by
> (mono) microphones, converting from stereo to mono should in theory have
> *no* effect.

There were many recordings where the audio was only playing in one
channel (e.g., if I had headphones on, I'd only hear the voice speaking
the stamp description in my left ear, and silence on my right).

That said... sounds like possibly I goofed some things up. :-|


> I guess the reason that you saved 100 MB, is simply that you
> lossily recompressed a lossy format, further reducing the quality
> (introducing more artefacts).
> 
> 
> > Today, I did further work, this time to reduce the bitrate of sounds,
> > so they are never higher than 32,000bps.  That saved another 41MB.
> 
> Is this based on the already recompressed (mono) file? This will introduce
> even more artefacts. You will have have encoded the file *three* times,
> losing quality at each step:
> 
>     Original → Encode to Ogg → Reencode (mono) → Reencode (bitrate)
> 
> See https://wiki.hydrogenaud.io/index.php?title=Transcoding
> 
> It would be much better to encode to the final format from the *original*
> uncompressed files (if you have them).

Oof, yes, I would have to dig them back up from an earlier release
I suppose.

I admit, a lot of the localized sound samples we have were done
by children in noisy environments and the quality of the recordings
were very bad to begin with.  I cast a wide net when I decided to
try and shrink the filesize of the sound files.  We have nearly 17,000
of them in tuxpaint-stamps; it felt like a months-long full-time job
to sort out which ones would _truly_ benefit, and I guess I didn't
expect much degregation happening to the higher-quality ones, by
reencoding them to be smaller. (They still certainly sound way better
than the ones which were bad recordings to begin with, to my ears.)


> I have tried listening to the transcoded Norwegian Nynorsk files. They were
> already in mono, so there is only a single recompression, but the audio
> quality is noticeably worse.
> 
> I have the original files, and can compress the files to ~ 32 kbps. This
> should results in much higher-quality files.
> 
> BTW, the algorithm for recompressing the files is also misguided. You first
> test if the bitrate is higher than 32 kbps. If it is, you recompress to 32
> kbps. But the bitrate in Ogg Vorbis is a *nominal* bitrate, and you might
> actually end up with a file that is bigger than 32 kbps after recompressing.
> Also, if the quality of the original file is such that it doesn’t *need* 32
> kbps, you’re encoding at an unnecessarily *high* bitrate. It would better to
> specify the quality (e.g., the ‘--quality’ argument in oggenc, for example
> to -1).

Thanks for explaining!


> BTW, would it be possible for Tux Paint to support the Opus codec? This
> results in much lower file sizes for the *same* quality. In my tests, I can
> get the same quality as my original Ogg files but halving the file size (by
> compress the original .wav files and using ‘opusenc --bitrate 24’ – and note
> that despite the name, the ‘--bitrate’ argument specifies the *quality*, not
> the actual bitrate).

I assume we could based on

  https://wiki.libsdl.org/SDL2_mixer/FrontPage

  It supports 8 channels of 16 bit stereo audio, plus a single channel
  of music. It can load FLAC, MP3, Ogg, VOC, and WAV format audio. It
  can also load MIDI, MOD, and Opus audio, depending on build options
  (see the note below for details.)

although:

  Support for software MIDI, MOD, and Opus are not included by default
  because of the size of the decode libraries, but you can get them by
  running external/download.sh


So what do you think, should I open some tickets for these things?
e.g.:

 1. restore original sound files from pre-12/2024 and
    do a smarter job at compressing them, doing all of this
    at once (rather than lossily one step at a time):

    a. stereo->mono the truly bad stereo (sound in one channel,
       silence in the other) recordings

    b. reduce the quality level

 2. investigate use of the Opus codec

    a. ensure it's usable on all major platforms
       (I assume Windows, Linux, macOS, and Android are good;
       Haiku would be the main question)

    b. using the files as they existed after step 1a,
       re-encode using Opus codec; assuming the file size
       is better (smaller) over all, use it

Thanks again!

-bill!


> 
> 
> -- 
> Karl Ove Hufthammer


> _______________________________________________
> Tuxpaint-stamps mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-stamps

Re: [Tuxpaint-i18n] Reduced bitrate of many stamp description sounds

[Karl O. H. <ka...@hu...>]

[Sorry for the late reply to this.]

Bill Kendrick skreiv 12.01.2024 06:05:
> The other day I went through and converted all descriptive sound files
> in Tux Paint Stamps -- the sounds of people speaking the names of
> stamps -- from stereo to mono.  That saved almost 100MB of space
> used by those OGG files!

I think this is misguided. Ogg Vorbis uses channel coupling (similar to 
joint stereo in the MP3 format), and since the recordings have been done 
by (mono) microphones, converting from stereo to mono should in theory 
have *no* effect. I guess the reason that you saved 100 MB, is simply 
that you lossily recompressed a lossy format, further reducing the 
quality (introducing more artefacts).


> Today, I did further work, this time to reduce the bitrate of sounds,
> so they are never higher than 32,000bps.  That saved another 41MB.

Is this based on the already recompressed (mono) file? This will 
introduce even more artefacts. You will have have encoded the file 
*three* times, losing quality at each step:

     Original → Encode to Ogg → Reencode (mono) → Reencode (bitrate)

See https://wiki.hydrogenaud.io/index.php?title=Transcoding

It would be much better to encode to the final format from the 
*original* uncompressed files (if you have them).

I have tried listening to the transcoded Norwegian Nynorsk files. They 
were already in mono, so there is only a single recompression, but the 
audio quality is noticeably worse.

I have the original files, and can compress the files to ~ 32 kbps. This 
should results in much higher-quality files.

BTW, the algorithm for recompressing the files is also misguided. You 
first test if the bitrate is higher than 32 kbps. If it is, you 
recompress to 32 kbps. But the bitrate in Ogg Vorbis is a *nominal* 
bitrate, and you might actually end up with a file that is bigger than 
32 kbps after recompressing. Also, if the quality of the original file 
is such that it doesn’t *need* 32 kbps, you’re encoding at an 
unnecessarily *high* bitrate. It would better to specify the quality 
(e.g., the ‘--quality’ argument in oggenc, for example to -1).

BTW, would it be possible for Tux Paint to support the Opus codec? This 
results in much lower file sizes for the *same* quality. In my tests, I 
can get the same quality as my original Ogg files but halving the file 
size (by compress the original .wav files and using ‘opusenc --bitrate 
24’ – and note that despite the name, the ‘--bitrate’ argument specifies 
the *quality*, not the actual bitrate).


-- 
Karl Ove Hufthammer

[Tuxpaint-i18n] Please submit translations for Tux Paint 0.9.33

[Bill K. <nb...@so...>]

I'm hoping to release Tux Paint 0.9.33 in the coming weeks.
The major new features include:

 * Transparent erasers
 * Filled polygon drawing magic tool
 * Dithered pixel magic tools
 * Variations of the "3D Glasses" magic tool
 * Ability to ungroup Magic tools (make it one big list)
 * Brush descriptions

Srings have changed or been added to the various parts of the project
(not just `tuxpaint`, but also `tuxpaint-config` and `tuxpaint-docs`,
of course; also the website, of course).

If you'd like to get translation updates included in 0.9.33, please
commit them to the Git repositories at SourceForge if you have
access, or if you've cloned the project, commit to your own repo
and make a Pull Request.  Or, of course, you can just email me your
PO file(s) and I can commit them on your behalf.

As usual, see https://tuxpaint.org/help/po/ for details as well.

Thanks in advance!  I hope everyone is staying well!

-bill!

Re: [Tuxpaint-i18n] Localized names of file paths?

[Mark K. <mar...@gm...>]

Resending to the mailing list without the attachment (it was blocked).  The
attachment was sent directly to Bill.

Thanks,
Mark

On Sat, Apr 27, 2024 at 4:07 PM Mark Kim <mar...@gm...> wrote:

> Hi Bill,
>
> When you run macOS in a non-native language, the names of the system
> folders do not change on the underlying file system.  This allows a program
> written for one language expecting the system folders in specific paths to
> be able to run on macOS running in another language mode.
>
> However, the GUI (Finder) may display the folder with a localized name.
> FYI, the way Finder does this for a system folder as follows: If the folder
> contains a 0-size hidden file named ".localized" in the folder, it looks
> for the localized version of the folder name from
> /System/Library/CoreServices/SystemFolderLocalizations/<lang>[_variant].lproj/SystemFolderLocalizations.strings.
> *.strings are basically Apple's version of *.mo files.
>
> It took some effort but I managed to get all *.strings files in
> /System/Library/CoreServices/SystemFolderLocalizations/<lang>[_variant].lproj/SystemFolderLocalizations.strings
> decoded on the version of macOS I'm running.* Their outputs are attached if
> you want to use them for the translations.
>
> * — In case anyone finds it useful, you can decode *.strings file using
> `plutil -p <filename.strings>`.  It turns out *.strings have the same
> format as *.plist, and *.plist can be decoded using plutil as per this
> post <https://stackoverflow.com/a/15907321/20025913> on StackOverflow.
>
>
> Thanks,
> Mark
>
> On Sat, Apr 27, 2024 at 2:31 PM Bill Kendrick <nb...@so...> wrote:
>
>>
>> I'm doing a little bit of work over in the `tuxpaint-docs` repo
>> (the PHP + gettext source of the HTML docs that are then sync'd
>> over to the main `tuxpaint` repo, to be part of a release) to
>> modularize how filenames and paths are managed.
>>
>> That is, rather than every time I want to mention the file
>> "/home/tuxpaint/.tuxpaintrc" (the user-level configuration
>> file for Tux Paint, on Linux/Unix) -- which sometimes I might
>> instead describe as "~/.tuxpaintrc" or "$HOME/.tuxpaintrc",
>> I'll instead use a little bit of PHP that will grab a string
>> that will be consistent across all of the documentation.
>> (e.g., "<?= $PATHS["linux"]["config"]["user"] ?>").
>>
>> To that end, it seems that some operating systems provide
>> localized versions of their rather descriptive paths,
>> e.g. on Windows there's "Program Files", and "Application Data".
>> (And for example, it looks like the latter is actually named
>> "Anwendungsdaten" (German), "Dati applicazioni" (Italian),
>> "Datos de programa" (Spanish), & "Dane aplikacji", per a random
>> Stackoverflow question I just landed on[*].
>>
>> I haven't figured it out yet, but does macOS or other OSes do
>> this (e.g., macOS has folders named "Library", "Application Support",
>> "Users", etc. -- do they have different names under different locales?)
>>
>> Basically, I want to make sure we do some amount of reasonable
>> localizing in the documentation, without going wild (and without
>> being inaccurate; e.g., if it's _always_ "Application Support",
>> even on a German Mac, there's no reason to _mis_-label it with
>> a localized string, in our docs).
>>
>> Thanks in advance for whatever you can share,
>>
>> [*]
>> https://stackoverflow.com/questions/4899985/windows-documents-and-settings-in-another-languages
>>
>> --
>> -bill!
>> Sent from my computer
>>
>>
>> _______________________________________________
>> Tuxpaint-i18n mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-i18n
>>
>

Re: [Tuxpaint-i18n] Localized names of file paths?

[Bill K. <nb...@so...>]

On Sat, Apr 27, 2024 at 11:30:41AM -0700, Bill Kendrick wrote:
> 
> I'm doing a little bit of work over in the `tuxpaint-docs` repo
> (the PHP + gettext source of the HTML docs that are then sync'd
> over to the main `tuxpaint` repo, to be part of a release) to
> modularize how filenames and paths are managed.

I'm done (for now) reworking a lot of places throughout the docs.
I wanted to let folks know that in a few places, I simplified
things, meaning fewer strings (since I use the same string
more consistently.)

However, in many places, I replaced junk like this:

  sprintf(
    gettext("The file is \"%s\".",
    "<code>/path/to/file.txt</code>")
  )

with junk like this:

  sprintf(
    gettext("The file is %s.",
    code_path(
      $PATHS['os']['somefile'],
      true /* wrap in quotes */
    )
  )

As you can see the quotes (") around the string argument (%s)
have been removed.  This is going to cause a lot of strings
in the PO files to get out of date, sorry about that. :-(

The reason was to prevent the plaintext renderings of the
documentation (HTML -> TXT) to end up wordwrapping awkwardly,
like so:

  The file is "
  /path/to/file.txt".

Under the hood, it means the HTML changes from, in the worst
case scenario:

  The file is "<code>/path/to/file.txt</code>".

...meaning even the path itself could word-wrap:

  The file is "/path/
  to/file.txt".

To this:

  The file is <nobr>"<code>/path/to/file.txt</code>"</nobr>.

...so the file path will never get split up, it will appear as:

  The file is
  "/path/ot/file.txt".

Hopefully the above all makes sense.

Along with avoiding splits on "/" or "\" (Windows), it
also prevents splits on any folder names that contain
spaces (like "C:\Program Files\" on Windows). :-)


I'm certain I have a lot more clean-up I can do in there,
which will undoubtedly cause even _more_ strings to change
a little.  I'm hopeful the improvement in consistency
(and lack of weird word wrapping) is worth the annoyance. :^)


-bill!

[Tuxpaint-i18n] Localized names of file paths?

[Bill K. <nb...@so...>]

I'm doing a little bit of work over in the `tuxpaint-docs` repo
(the PHP + gettext source of the HTML docs that are then sync'd
over to the main `tuxpaint` repo, to be part of a release) to
modularize how filenames and paths are managed.

That is, rather than every time I want to mention the file
"/home/tuxpaint/.tuxpaintrc" (the user-level configuration
file for Tux Paint, on Linux/Unix) -- which sometimes I might
instead describe as "~/.tuxpaintrc" or "$HOME/.tuxpaintrc",
I'll instead use a little bit of PHP that will grab a string
that will be consistent across all of the documentation.
(e.g., "<?= $PATHS["linux"]["config"]["user"] ?>").

To that end, it seems that some operating systems provide
localized versions of their rather descriptive paths,
e.g. on Windows there's "Program Files", and "Application Data".
(And for example, it looks like the latter is actually named
"Anwendungsdaten" (German), "Dati applicazioni" (Italian),
"Datos de programa" (Spanish), & "Dane aplikacji", per a random
Stackoverflow question I just landed on[*].

I haven't figured it out yet, but does macOS or other OSes do
this (e.g., macOS has folders named "Library", "Application Support",
"Users", etc. -- do they have different names under different locales?)

Basically, I want to make sure we do some amount of reasonable
localizing in the documentation, without going wild (and without
being inaccurate; e.g., if it's _always_ "Application Support",
even on a German Mac, there's no reason to _mis_-label it with
a localized string, in our docs).

Thanks in advance for whatever you can share,

[*] https://stackoverflow.com/questions/4899985/windows-documents-and-settings-in-another-languages

-- 
-bill!
Sent from my computer

[Tuxpaint-i18n] Brushes may have [localized] descriptions

[Bill K. <nb...@so...>]

I've finally added a small feature that allows brushes to
have descriptions that appear (rather than generic instructions)
when you select them.

This is being handled basically identically to how Stamp
descriptions are handled.  Each brush may have an optional
".txt" file which includes the description in a variety of
languages.

A pair of scripts (cribbed from `tuxpaint-stamps`) are used
to sync the text in these files with some new PO files and
a POT file.

If you'd like to translate them, you can see the new
file "tuxpaint-brushes.pot" inside the main "tuxpaint"
source code repository, under a new "brushes-po" subdirectory:

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/brushes-po/

Links to the files, and the translation statistics for this
new domain, are also available on the "Help Us Translate"
page of the website:

  https://tuxpaint.org/help/po/#tpb

(It's only 15 strings, and I don't expect it to get much
larger any time soon.)

Thanks!

-- 
-bill!
Sent from my computer

[Tuxpaint-i18n] Please send any updates for Tux Paint 0.9.32

[Bill K. <nb...@so...>]

This weekend I'm hoping to put together a release candidate ("rc") of Tux Paint
version 0.9.32, so the port maintainers (Luc, Mark, Pere, Shin-ichi, etc.) can
build beta versions for users to test.

If you have any localization updates (translation strings, audio files, etc.)
that you'd like to be part of the next release, please commit them to the
appropriate Git repo (if you have access) or email them to me soon.

Thanks in advance!

-- 
-bill!
Sent from my computer

[Tuxpaint-i18n] Axonometric & Oblique drawing tools (Was re: New perspective drawing tools & complexity setting)

[Bill K. <nb...@so...>]

On Sat, Dec 30, 2023 at 02:24:46PM -0800, Bill Kendrick wrote:
> 
> Hi all, and happy new year!
> 
> Just a heads-up that some development for the next version of
> Tux Paint has been done, and I've added a set of new drawing
> tools for drawing in 1-Point, 2-Point, and 3-Point perspective,
> as well as adjusting/positioning vanishing points.

Hi again!  Over the past few days I added another set of tools,
similar to these (within the same plug-in source file, in fact):

 * Isometric
 * Dimetric
 * Trimetric
 * Oblique

These tools, as well as the N-Point Perspective tools, only allow you
to draw lines in certain directions.  The perspective tools draw
different angles based on _where_ you draw the line (so for example,
in 1-Point perspective, your diagonal lines might always go
towards/away-from the center).  With these tools, where you draw the
line doesn't matter.

For example, the Isometric tool lets you draw vertically (up/down; 90
and 270 degrees), and diagonally at 30 degree, 150 degree, 210 degree,
and 330 degree angles.

The Dimetric tool allows you to adjust the angle; it will be the
same on both sides (mirrored across the vertical axis).

The Trimetric tool allows you to adjust both angles.

The Oblique tool draws both vertically (90 & 270 degrees) and
horizontally (0 & 180 degrees), and at a single angle that you
can adjust.

Similar to the N-Point Perspective modes, when Tux Paint is in
"beginner" complexity mode, the angles of the Di- & Trimetric and
Oblique tool cannot be adjusted.  However, similar to how that
mode provides two alternate versions of 3-Point Perspective,
two Oblique tools are made available -- one where the angle goes
45 (& 225) degrees ("up and to the right"), and another where it
goes 135 (and 315) degrees ("up and to the left").

Here are some example screenshots:

 * Isometric
   https://tuxpaint.org/latest/sshots/tuxpaint-0.9.32-iso-draw.png
   https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/docs/html/images/magic_examples/isometric_line.png

 * Dimetric
   https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/docs/html/images/magic_examples/dimetric_draw.png

 * Trimetric
   https://tuxpaint.org/latest/sshots/tuxpaint-0.9.32-tri-draw.png
   https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/docs/html/images/magic_examples/trimetric_draw.png

 * Oblique
   https://tuxpaint.org/latest/sshots/tuxpaint-0.9.32-oblique-draw.png
   https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/docs/html/images/magic_examples/oblique_draw.png


All of these tools make heavy and constant use of trionometric
functions (COS(), SIN(), and ATAN2()), and I noticed they were a bit
slow on my Google Pixel 7 Android phone when I tried out a test build
Pere made (for other reasons).

I began looking into how to address performance issues in this
plugin, but I didn't get very far.  I wonder how much of it is
general slowness of certain operations in Tux Paint (e.g., XOR'ing
pixels while clicking/dragging these tools -- they offer helpful
guides so you can line things up).  I'd appreciate any help in this
department, as I'm be a bit burnt out now. :-D

Additionally, the tools would benefit from a grid-snapping feature,
which would help ensure things line up well (at the cost of some
fine positioning -- I feel if you're at that level of expertise
it might be time to switch to Krita or GIMP ;-) ).

However, in the dark and cold middle of the night, I threw a virtual
10x10 pixel grid on the canvas, by doing this to all mouse positions:

  x = (x / 10) * 10;
  y = (y / 10) * 10;

...but that was hilariously naive.  While it's great for lining up
vertical and horizontal lines, these tools are all about helping you
draw diagonal lines.  So the grids would need to be aware of the
valid angles!

e.g., sure I could lock to 10-pixel grid horizontally, but in
doing so my vertical grid would need to be based on the possible
angle(s) -- e.g., 30 degrees in Isometric, 45 (or user's choice)
in Dimetric and Oblique, 30 and 15 (or user's choices) in Trimetric.

My brain is done doing math, for the moment.  I might just open
up a set of tickets for these issues, and punt them to a future
release. ;)


Speaking of which, I think it might be time for a new release soon!
I've added 9 new magic tools (not counting the various vanishing
point and angle editors for the ones noted in this thread).

I've already drafted the press release, and I THINK everything
else is in good order...  (My efforts to reduce the size of
some sound files in the Stamps collection was able to shave
off 100MB, or about 40%(!), from the size of the Android APK
when it includes both TP & Stamps!)

Whew!

-bill!

Re: [Tuxpaint-i18n] [Tuxpaint-stamps] Reduced bitrate of many stamp description sounds

[Bill K. <nb...@so...>]

On Thu, Jan 11, 2024 at 09:05:05PM -0800, Bill Kendrick wrote:
<snip>
> Today, I did further work, this time to reduce the bitrate of sounds,
> so they are never higher than 32,000bps.  That saved another 41MB.
<snip> 
> Since the bitrate change is technically destructive (but not
> noticable to my ears), I decided NOT to commit all of the changes
> at once, but instead am doing so on a per-language,
> per-top-level-directory basis.
> 
> e.g., all BE "animals", then all CA "animals", ... then all BE "space",
> then all CA "space", then all FR "space", ... and so on...

BTW I forgot to mention, I did this with a one-off BASH command
(no reason to save it as a shell script in `tools`):


for i in `ls`; do
  echo "============================================================="
  for j in `echo "be bg ca da el es fr lt ml nl nn ro ru"`; do
    echo "-------------------------------------------------------------"
    echo $i - $j
    git add `find $i -name "*_desc_$j.ogg"`
    git commit -m "Reduce bitrate of $j descriptions of $i stamps"
    git push
  done
done


FYI!

-bill!

[Tuxpaint-i18n] Reduced bitrate of many stamp description sounds

[Bill K. <nb...@so...>]

The other day I went through and converted all descriptive sound files
in Tux Paint Stamps -- the sounds of people speaking the names of
stamps -- from stereo to mono.  That saved almost 100MB of space
used by those OGG files!

Today, I did further work, this time to reduce the bitrate of sounds,
so they are never higher than 32,000bps.  That saved another 41MB.

In both cases, I used BASH shell scripts (commited in the
`tuxpaint-stamps` repository, under the `tools` subdirectory) here on
my Linux laptop.  They use FFMPEG tools (`ffmpeg` itself, and the
latter uses `ffprobe` to check the bitrate, and skip those that
are already at <= 32,000bps).

Since the bitrate change is technically destructive (but not
noticable to my ears), I decided NOT to commit all of the changes
at once, but instead am doing so on a per-language,
per-top-level-directory basis.

e.g., all BE "animals", then all CA "animals", ... then all BE "space",
then all CA "space", then all FR "space", ... and so on...


This will allow us to revert one or more commits, to recover
files which anyone might decide does not sound enough now,
without having to revert ALL of the changes at once! 8^o

At 14 languages x 16 top-level, it could be as many as
224 commits!  It's going to have been fewer than that, though,
as not every category of stamp has descriptions in every
language, and even then not every sound file was encoded at
higher than 32Kbps.  (For example, none of the English files
needed to be touched, as they were mostly 32K; a few 8K.)

Anyway, if anyone notices any descriptive sounds in their favorite
locale sounding bad -- well, worse than they did already (many are
VERY poor quality recordings; but beggars can't be choosers!) --
then please alert me and we can look at whether it's worth
reverting the pre-2024-01-11 versions of the OGG files in question,
and consider other ways to reduce their size.


Ref: https://sourceforge.net/p/tuxpaint/bugs/284/

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] Translation Issues

[Bill K. <nb...@so...>]

On Sat, Jan 06, 2024 at 01:59:11PM +0200, Ελένη Τσερμεντσέλη wrote:
> Hello and Happy New Year,
> These days i was testing whether the translation in Greek works
> properly.What i figured out was that :
> a)When i pick certain tools like "shapes","fills","labels",the mascot's
> instructions on the bottom of the window are not translated in Greek.
> 
> b)Moreover when selecting a certain  tool (like shapes),there are some
> options on the right of the window that are not translated in Greek, while
> some others are .
> 
> https://i.postimg.cc/XJN7Dbmk/2024-01-03-230109.png
> 
> https://i.postimg.cc/wM3RTTn0/2024-01-03-230212.png

Hi thanks for the note.  The "Hexagon" shape was added to the "Shapes"
tool relatively recently -- in version 0.9.28 released in mid-2022.
It appears the most recent updates to the Greek translation of
strings inside Tux Paint came about 9 months prior to that.

If you, or anyone you know, would like to help update Tux Paint's
translation to Greek, this page has information explaining how we
handle localizations, and how people can participate/contribute:

  https://tuxpaint.org/help/

The strings themselves are in "gettext" catalogs (PO files), and are
split between the various modules of Tux Paint:

 * the program itself (including all the built-in drawing tools and the magic tools)
 * the collection of "Stamps" artwork
 * the configuration program ("Tux Paint Config.")
 * the documentation (so far, just Tux Paint itself)
 * and the website (split between "high priority" pages, like the homepage,
   download pages, etc.; and "low priority" pages, like reviews,
   downloads for older platforms like Windows95, etc.).

Links to those files may all be found here [1]:

  https://tuxpaint.org/help/po/

As you can see, the translations into Greek are currently at
these levels of completion:

 * Tux Paint - 55%
 * Stamps - 99% [2]
 * Tux Paint Config. - 73%
 * Website - High-priority: 38%, Low-priority: 17%

Note that, as we add or change features to Tux Paint over time, the
translations always get "out of date", so this is always an ongoing
battle. :-)  Also, as volunteers who provide the translations
become busy with other things in their lives, or decide to stop
participating in the project, the translations can stagnate.
(For example, we received some translations to Tibetan back in 2006,
and that's the last we ever received!)

I hope this all makes sense.  Thanks & happy new year to you as well!


[1] I'm also happy to grant access to the Git repositories over on the
    SourceForge project for Tux Paint, so I don't need to act as
    a middle-man.

[2] We haven't added new stamps (or changed their descriptions)
    in a very long time, which is why the level of completion for
    Greek is very high... nothing new has been added to make it
    become out-of-date.

-- 
-bill!
Sent from my computer

[Tuxpaint-i18n] Translation Issues

[Ελένη Τ. <ele...@gm...>]

 Hello and Happy New Year,
These days i was testing whether the translation in Greek works
properly.What i figured out was that :
a)When i pick certain tools like "shapes","fills","labels",the mascot's
instructions on the bottom of the window are not translated in Greek.

b)Moreover when selecting a certain  tool (like shapes),there are some
options on the right of the window that are not translated in Greek, while
some others are .

https://i.postimg.cc/XJN7Dbmk/2024-01-03-230109.png

https://i.postimg.cc/wM3RTTn0/2024-01-03-230212.png

[Tuxpaint-i18n] New perspective drawing tools & complexity setting

[Bill K. <nb...@so...>]

Hi all, and happy new year!

Just a heads-up that some development for the next version of
Tux Paint has been done, and I've added a set of new drawing
tools for drawing in 1-Point, 2-Point, and 3-Point perspective,
as well as adjusting/positioning vanishing points.

Further to that, I've added a new "complexity" setting, that
allows a user to specify their expertise level with Tux Paint
(or art software, or computers in general), which allows some
Magic tools to behave differently.

For example, the perspective drawing tools mentioned above will
normally (in the default "advanced" complexity mode) appear as
six different magic tools: three for drawing, and three for
adjusting their respective vanishing point(s).

However, in "beginner" mode, only drawing tools will be made
available; you're stuck with the default vanishing points.
In fact, a fourth drawing tool, an alterlative version of the
3-point perspective, will be made available in this case.
(One for drawings "looking up from below", and the alternative
for "looking down from above".)

Lots of strings have been added (or in some cases changed) based
on this work, and a bunch of other things I've done recently *,
so if you've got the time & interest, please grab the latest
PO files and send me (or commit back, if you have Git access)
updates.

Thanks as always, and take care!  Wishing you all the best for 2024,

-bill!

* All over the place: `tuxpaint`, `tuxpaint-docs`, `tuxpaint-website`,
  `tuxpaint-config` repos.  See https://tuxpaint.org/help/po as always.

Re: [Tuxpaint-i18n] Translation of Android build miniconfig tool

[Pere P. i C. <per...@gm...>]

El dv. 22 de 12 de 2023 a les 09:16 +0100, en/na Jacques Chion va escriure:
> Le 21/12/2023 à 19:13, Pere Pujal i Carabantes a écrit :
> > Hi all,
> > After a long delay after its launch, Tux Paint 0.9.31 is becoming ready for Android.
> > If you want to get its mini config tool translated to your language, please do it. :)
> > 
> > 
> 
> Hello Pere,
> 
> just one question :
> must we translate the string "msgctxt" ?
> poedit in ubuntu does not handle that.

No, don't translate it.
msgctxt is informative about where the text will be displayed.

Thanks
Pere

Re: [Tuxpaint-i18n] Translation of Android build miniconfig tool

[Jacques C. <jac...@or...>]

Le 21/12/2023 à 19:13, Pere Pujal i Carabantes a écrit :
> Hi all,
> After a long delay after its launch, Tux Paint 0.9.31 is becoming ready for Android.
> If you want to get its mini config tool translated to your language, please do it. :)
> 
>

Hello Pere,

just one question :
must we translate the string "msgctxt" ?
poedit in ubuntu does not handle that.

Regards

Jacques

[Tuxpaint-i18n] Translation of Android build miniconfig tool

[Pere P. i C. <per...@gm...>]

Hi all,
After a long delay after its launch, Tux Paint 0.9.31 is becoming ready for Android.
If you want to get its mini config tool translated to your language, please do it. :)

The updatable existing translations are at
https://github.com/tux4kids/Tuxpaint-Android/tree/master/app/src/main/locale

or if your language is not one of those, the template.po file is at
https://github.com/tux4kids/Tuxpaint-Android/raw/master/app/src/main/locale/template.pot

Thanks
Pere

Re: [Tuxpaint-i18n] Tux Paint 0.9.31 coming soon; send translation updates!

[Bill K. <nb...@so...>]

On Fri, Jun 30, 2023 at 08:47:32AM +0200, Karl Ove Hufthammer wrote:
<snip>
> I’m using the tuxpaint Git repo. For example, the .po files and
> tuxpaint.pot contain this string:
> 
>     Eraser tool now offers fuzzy erasers.
> 
> But the source file (org.tuxpaint.Tuxpaint.appdata.xml.in) has this
> updated string:
> 
>     Eraser tool now offers fuzzy (soft-edged) erasers.

Oh drat.  Yes I forgot to run update-po.sh after tweaking that
file.  (The strings in there are not wrapped in "gettext()" like
they are in the C code and PHP stuff, so I easily forget!)

Mending now, thanks for reporting!

-bill!