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

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

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

Bill Kendrick skreiv 30.06.2023 06:51:
> On Thu, Jun 29, 2023 at 09:08:26PM +0200, Karl Ove Hufthammer wrote:
>> The PO files themselves are not up-to-date. The source code contains
>> string changes not reflected in the PO and POT files. Is this
>> intentional?
> […]
>
> What strings are you seeing (which repo, and which source file(s))
> that don't appear to be reflected in the POT and PO files?

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.


-- 
Karl Ove Hufthammer

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

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

On Thu, Jun 29, 2023 at 09:08:26PM +0200, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 27.06.2023 21:18:
> >As usual,https://tuxpaint.org/help/po/  can give you an idea
> >of how up-to-date the various PO files are.
> 
> The PO files themselves are not up-to-date. The source code contains
> string changes not reflected in the PO and POT files. Is this
> intentional?

The stats on that page are not up-to-the-minute, but the links
(which now only go directly to the PO files in the Git repo in
SourceForge) should be.

What strings are you seeing (which repo, and which source file(s))
that don't appear to be reflected in the POT and PO files?
It could be that something slipped through without being
wrapped in `gettext()`, or missing from a POTFILES.in file. :-/

Thanks!

-bill!

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

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

Bill Kendrick skreiv 27.06.2023 21:18:
> As usual,https://tuxpaint.org/help/po/  can give you an idea
> of how up-to-date the various PO files are.

The PO files themselves are not up-to-date. The source code contains 
string changes not reflected in the PO and POT files. Is this intentional?


-- 
Karl Ove Hufthammer

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

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

On Tue, Jun 27, 2023 at 09:30:36PM +0200, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 27.06.2023 21:18:
> >If you'd like to get translation updates included in the next
> >release of these packages, please commit them, or email them
> >directly to me, soon!
> 
> Do you have a (tentative) release date?

Never ;-D

But I'd say probably no sooner than late next week.  It mostly depends
on whether the builds for Windows, macOS, RPM Linux, Android, etc.
all continue to work after all of the little changes.


-- 
-bill!
Sent from my computer

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

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

Bill Kendrick skreiv 27.06.2023 21:18:
> If you'd like to get translation updates included in the next
> release of these packages, please commit them, or email them
> directly to me, soon!

Do you have a (tentative) release date?


-- 
Karl Ove Hufthammer

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

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

Tux Paint, Tux Paint Config., and (as usual) the Tux Paint website,
have been getting updated recently to add new strings, or change
existing ones, ahead of release of Tux Paint 0.9.31 and
Tux Paint Config 0.0.22.  (So far there have been no changes to
Tux Paint Stamps since since the May release.)

If you'd like to get translation updates included in the next
release of these packages, please commit them, or email them
directly to me, soon!

As usual, https://tuxpaint.org/help/po/ can give you an idea
of how up-to-date the various PO files are.

Thanks in advance,

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] [Tuxpaint-devel] Per-locale default font

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

On Mon, Jun 12, 2023 at 10:18:35PM -0700, Bill Kendrick wrote:
> On Mon, Jun 12, 2023 at 09:17:55PM -0700, Bill Kendrick wrote:
> <snip> 
> > Yeah, I think that's what's happening for me on Linux as well.
> > Ever since switching from SDL_ttf and attempting to load "<locale>.ttf"
> > files, to SDL_Pango (now SDL2_Pango), we basically lost the ability to
> > use those fonts, and have been shipping them meaninglessly.  :-D  Oops!
> <snip> 
> > Of course, going back to the beginning of this email, the main issue at
> > hand is Tux Paint, via SDL2_Pango, doesn't KNOW about these fonts yet.
> > At least, not for me, not on Linux!
> 
> Well, I tried to convince FontConfig to add Tux Paint's shipped fonts
> (hard-coding `/usr/local/share/tuxpaint/fonts/` for the moment) to
> the list of directories to look at, but it seems to be refusing to. :-/
> 
> Anyone out here have any experience with this stuff?

Argh, I think I figured it out, unless I'm hallucinating or testing
it all wrong. :)  (I was adding Tux Paint's font directory _after_
we tried loading the uifont.)

I'm going to further extend things a bit to allow for alternative
fonts (e.g., if you have a full font, use that rather than Tux Paint's
subset alternative; e.g. for Chinese Traditional).

And I'm also going to try and get Tux Paint Config. to do the same
thing (ask FontConfig to look at Tux Paint's font directory, before
Tux Paint Config. tries to load and list available fonts in its UI).

-bill!

Re: [Tuxpaint-i18n] [Tuxpaint-devel] Per-locale default font

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

On Mon, Jun 12, 2023 at 09:17:55PM -0700, Bill Kendrick wrote:
<snip> 
> Yeah, I think that's what's happening for me on Linux as well.
> Ever since switching from SDL_ttf and attempting to load "<locale>.ttf"
> files, to SDL_Pango (now SDL2_Pango), we basically lost the ability to
> use those fonts, and have been shipping them meaninglessly.  :-D  Oops!
<snip> 
> Of course, going back to the beginning of this email, the main issue at
> hand is Tux Paint, via SDL2_Pango, doesn't KNOW about these fonts yet.
> At least, not for me, not on Linux!

Well, I tried to convince FontConfig to add Tux Paint's shipped fonts
(hard-coding `/usr/local/share/tuxpaint/fonts/` for the moment) to
the list of directories to look at, but it seems to be refusing to. :-/

Anyone out here have any experience with this stuff?

I added a bit of (all-the-time, for now) debugging output to stdout
to have Tux Paint dump the directories where FontConfig is looking.
On my system, for example, I get:

FontConfigGetFontDirs():
 * /usr/share/fonts
 * /usr/local/share/fonts
 * /home/kendrick/.local/share/fonts
 * /home/kendrick/.fonts
 * /usr/share/fonts/croscore
 * /usr/share/fonts/crosextra
 * /usr/share/fonts/dejavu
 * /usr/share/fonts/ko-nanum
 * /usr/share/fonts/lohit-cros
...
 * /usr/share/fonts/woff
 * /home/kendrick/.fonts/a
 * /home/kendrick/.fonts/e
 * /home/kendrick/.fonts/h
 * /home/kendrick/.fonts/kfontinst
 * /home/kendrick/.fonts/m
 * /usr/share/fonts/X11/Type1
 * /usr/share/fonts/X11/encodings
...
 * /usr/share/fonts/woff/opendyslexic
 * /usr/share/fonts/X11/encodings/large
 * /usr/share/fonts/truetype/roboto/unhinted
 * /usr/share/fonts/truetype/roboto/unhinted/RobotoTTF

Nowhere in there do I see the directory I'm trying to add
(/usr/local/share/tuxpaint/fonts/ or "locales/" under it).

;-(


On Sat, Jun 10, 2023 at 06:26:13PM -0400, Mark Kim wrote:
> Hi,
> 
> Tux Paint Config on macOS is also unable to list fonts bundled with Tux
> Paint.  This happens, at least on macOS, because the bundled fonts are not
> installed but stays bundled with Tux Paint, outside the purview of Tux
> Paint Config.

When/if we DO get this working in Tux Paint, I _think_ it should be
reasonable to just do the same thing in Tux Paint Config., to let it
find all the fonts Tux Paint ships with (wherever Tux Paint stores them,
e.g, in my case `/usr/local/share/tuxpaint/fonts/`), rather than having
to maintain a hard-coded list.

But... I dunno.  This stuff is maddeningly complicated. ;-(

Help wanted!!!

-bill!

Re: [Tuxpaint-i18n] [Tuxpaint-devel] Per-locale default font

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

On Sat, Jun 10, 2023 at 06:26:13PM -0400, Mark Kim wrote:
> Hi,
> 
> Tux Paint Config on macOS is also unable to list fonts bundled with Tux
> Paint.  This happens, at least on macOS, because the bundled fonts are not
> installed but stays bundled with Tux Paint, outside the purview of Tux
> Paint Config.

Yeah, I think that's what's happening for me on Linux as well.
Ever since switching from SDL_ttf and attempting to load "<locale>.ttf"
files, to SDL_Pango (now SDL2_Pango), we basically lost the ability to
use those fonts, and have been shipping them meaninglessly.  :-D  Oops!


> I've made this commit
> <https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/4cfd3155c5282ffa3f260af05d2a30fa1027da95/>
> to ensure fonts bundled with Tux Paint are always listed in UI Fonts
> section of Tux Paint Config.  This is done by hard-coding the list of
> bundled fonts.  The change affects all OS in hope that it'll be beneficial
> to other OS, but let me know if it should be made into a macOS-specific
> change.

I think this is okay (though we'll need to make sure it stays sync'd up
with Tux Paint, if/when we ever change anything!)

Way back in the day (literally 20 years ago, +/- a few months!) we
packaged up various fonts that were too big to include directly inside
Tux Paint, three of which are still available here:

  https://tuxpaint.org/download/fonts/

They include:

 * Korean (~10MB)
   The "ko.ttf" font file is a copy of "gulim.ttf" from the "Baekmuk" collection
   of Korean TrueType fonts, (c) 1986-2000, Baekmuk Font 21 Inc.
   (Came from Debian package "ttf-baekmuk", at the time.)

 * Chinese Traditional (~14MB)
   HanWangKaiMediumChuIn is a registered trademark of HtWang Graphics Laboratory
   (C)Copyright Dr. Hann-Tzong Wang, 2004.
   (GPL v2+)

   [Note: What we ship directly inside Tux Paint is a subset of another GPL
   font, "wp010-05.ttf", containing only the characters used by Tux Paint;
   it weighs in at 1.1MB.  Unfortunately, the Python script that generates it
   doesn't run under Python3.  Fortunately, I refreshed it back in early 2022.]

 * Chinese Simplified (~5MB)
   The "zh_cn.ttf" font file is a copy of "AR PL SungtiL GB",
   a high-quality Chinese TrueType font (gbsn00lp.ttf)
   generously provided by Arphic Technology to the Free Software community
   under the "Arphic Public License".

We used to have others available for download as well, but eventually
rolled them into Tux Paint itself.  I wonder if in this day & age it'd
be fine to simply include these last tree fonts directly inside
Tux Paint, too.  (It looks like it'd add about 28MB to the install size.)

I have no clue whether the Windows installers or macOS DMG from way back
in 2002 & 2004 still work properly with current Tux Paint!!!  I'd rather
not continue maintaining these separate downloads. :-)


Of course, going back to the beginning of this email, the main issue at
hand is Tux Paint, via SDL2_Pango, doesn't KNOW about these fonts yet.
At least, not for me, not on Linux!

I'll poke around.

-bill!


> 
> Thanks,
> Mark
> 
> 
> On Sat, Jun 10, 2023 at 9:33 AM Shin-ichi TOYAMA <
> dol...@wm...> wrote:
> 
> > Hi!
> >
> > The behavior of the font seartch methods seem to work differently on
> > Linux and Windows.
> >
> > On linux, Tux Paint and Tux Paint Config seems not be able to find a
> > locale font shipped with Tux Paint.
> >
> > On the other hand, they *can* find the locale font on windows.
> >
> >
> > I think "noto sans" (pango's default on Rocky9?) looks good, but MS
> > Gothic (default on Windows) looks quite bad.
> >
> > Please see some examples I wrapped up.
> >
> >   https://z1.plala.jp/tuxpaint/tmp/uifonts2.html
> >
> > I confirmed pango's default (noto sans) on Rocky9 is good enough and
> > guess TkaoPGothick also would not be bad. Therefore, just specifing
> > "GJGothicPNSubset" as a default for Japanese would be O.K. at least
> > for Japanese.
> >
> > However, how is it on other distro's? How is it for other languages?
> >
> > I think it would be better if we could find a way to use locale fonts
> > also on Linux.
> >
> > Thanks!
> >
> > On Thu, 8 Jun 2023 00:52:07 -0700, Bill Kendrick wrote:
> > >
> > >For a long while now, Tux Paint has used "DejaVu Sans" as the
> > >preferred font for the UI (requested via Pango, though based on what I
> > >see in screenshots on Twitter, some folks don't have that font and
> > >some alternatives are used).
> > >
> > >Recently, Shin-ichi noted that we have a font tucked away in
> > >"fonts/locale/" that looks much better for use with Japanese text,
> > >but we're not using it (we no longer load TTF files directly and use
> > >SDL_ttf to render strings, it's all SDL2_Pango now).
> > >
> > >Therefore, I've added the ability for us (the Tux Paint developers)
> > >to specify a preferred font on a per-locale basis.  It's simply
> > >a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
> > >German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
> > >describing the font family we want Pango to load.
> > >(If left unspecified, we'll continue to ask for "DejaVu Sans".)
> > >
> > >This is now in the Git master branch over in the SourceForge project,
> > >and will be part of Tux Paint 0.9.31.
> > >
> > >I'm about to try to set fonts, as best I can, based on the collection
> > >of TTF files we have been shipping with Tux Paint.  Those files seem
> > >to be useless now, unless I'm mistaken!  However, I wonder if we could
> > >install them into the system where Pango can find them, when installing
> > >Tux Paint?  Or perhaps we could somehow point Pango to our directory
> > >of locale fonts as an extra place to look when scanning for fonts...?
> > >
> > >Thoughts?
> > >
> > >And also, if you have a preferred font for your favorite locale,
> > >please share and I can add it to the list!
> > >
> >
> >
> > --
> > Shin-ichi TOYAMA <dol...@wm...>
> >
> >
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] [Tuxpaint-devel] Per-locale default font

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

Hi,

Tux Paint Config on macOS is also unable to list fonts bundled with Tux
Paint.  This happens, at least on macOS, because the bundled fonts are not
installed but stays bundled with Tux Paint, outside the purview of Tux
Paint Config.

I've made this commit
<https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/4cfd3155c5282ffa3f260af05d2a30fa1027da95/>
to ensure fonts bundled with Tux Paint are always listed in UI Fonts
section of Tux Paint Config.  This is done by hard-coding the list of
bundled fonts.  The change affects all OS in hope that it'll be beneficial
to other OS, but let me know if it should be made into a macOS-specific
change.

Thanks,
Mark


On Sat, Jun 10, 2023 at 9:33 AM Shin-ichi TOYAMA <
dol...@wm...> wrote:

> Hi!
>
> The behavior of the font seartch methods seem to work differently on
> Linux and Windows.
>
> On linux, Tux Paint and Tux Paint Config seems not be able to find a
> locale font shipped with Tux Paint.
>
> On the other hand, they *can* find the locale font on windows.
>
>
> I think "noto sans" (pango's default on Rocky9?) looks good, but MS
> Gothic (default on Windows) looks quite bad.
>
> Please see some examples I wrapped up.
>
>   https://z1.plala.jp/tuxpaint/tmp/uifonts2.html
>
> I confirmed pango's default (noto sans) on Rocky9 is good enough and
> guess TkaoPGothick also would not be bad. Therefore, just specifing
> "GJGothicPNSubset" as a default for Japanese would be O.K. at least
> for Japanese.
>
> However, how is it on other distro's? How is it for other languages?
>
> I think it would be better if we could find a way to use locale fonts
> also on Linux.
>
> Thanks!
>
> On Thu, 8 Jun 2023 00:52:07 -0700, Bill Kendrick wrote:
> >
> >For a long while now, Tux Paint has used "DejaVu Sans" as the
> >preferred font for the UI (requested via Pango, though based on what I
> >see in screenshots on Twitter, some folks don't have that font and
> >some alternatives are used).
> >
> >Recently, Shin-ichi noted that we have a font tucked away in
> >"fonts/locale/" that looks much better for use with Japanese text,
> >but we're not using it (we no longer load TTF files directly and use
> >SDL_ttf to render strings, it's all SDL2_Pango now).
> >
> >Therefore, I've added the ability for us (the Tux Paint developers)
> >to specify a preferred font on a per-locale basis.  It's simply
> >a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
> >German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
> >describing the font family we want Pango to load.
> >(If left unspecified, we'll continue to ask for "DejaVu Sans".)
> >
> >This is now in the Git master branch over in the SourceForge project,
> >and will be part of Tux Paint 0.9.31.
> >
> >I'm about to try to set fonts, as best I can, based on the collection
> >of TTF files we have been shipping with Tux Paint.  Those files seem
> >to be useless now, unless I'm mistaken!  However, I wonder if we could
> >install them into the system where Pango can find them, when installing
> >Tux Paint?  Or perhaps we could somehow point Pango to our directory
> >of locale fonts as an extra place to look when scanning for fonts...?
> >
> >Thoughts?
> >
> >And also, if you have a preferred font for your favorite locale,
> >please share and I can add it to the list!
> >
>
>
> --
> Shin-ichi TOYAMA <dol...@wm...>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-i18n] Per-locale default font

[Shin-ichi T. <dol...@wm...>]

Hi!

The behavior of the font seartch methods seem to work differently on 
Linux and Windows.

On linux, Tux Paint and Tux Paint Config seems not be able to find a 
locale font shipped with Tux Paint.

On the other hand, they *can* find the locale font on windows.


I think "noto sans" (pango's default on Rocky9?) looks good, but MS 
Gothic (default on Windows) looks quite bad.

Please see some examples I wrapped up.

  https://z1.plala.jp/tuxpaint/tmp/uifonts2.html

I confirmed pango's default (noto sans) on Rocky9 is good enough and 
guess TkaoPGothick also would not be bad. Therefore, just specifing 
"GJGothicPNSubset" as a default for Japanese would be O.K. at least
for Japanese.

However, how is it on other distro's? How is it for other languages?

I think it would be better if we could find a way to use locale fonts 
also on Linux.

Thanks!

On Thu, 8 Jun 2023 00:52:07 -0700, Bill Kendrick wrote:
>
>For a long while now, Tux Paint has used "DejaVu Sans" as the
>preferred font for the UI (requested via Pango, though based on what I
>see in screenshots on Twitter, some folks don't have that font and
>some alternatives are used).
>
>Recently, Shin-ichi noted that we have a font tucked away in
>"fonts/locale/" that looks much better for use with Japanese text,
>but we're not using it (we no longer load TTF files directly and use
>SDL_ttf to render strings, it's all SDL2_Pango now).
>
>Therefore, I've added the ability for us (the Tux Paint developers)
>to specify a preferred font on a per-locale basis.  It's simply
>a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
>German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
>describing the font family we want Pango to load.
>(If left unspecified, we'll continue to ask for "DejaVu Sans".)
>
>This is now in the Git master branch over in the SourceForge project,
>and will be part of Tux Paint 0.9.31.
>
>I'm about to try to set fonts, as best I can, based on the collection
>of TTF files we have been shipping with Tux Paint.  Those files seem
>to be useless now, unless I'm mistaken!  However, I wonder if we could
>install them into the system where Pango can find them, when installing
>Tux Paint?  Or perhaps we could somehow point Pango to our directory
>of locale fonts as an extra place to look when scanning for fonts...?
>
>Thoughts?
>
>And also, if you have a preferred font for your favorite locale,
>please share and I can add it to the list!
>


-- 
Shin-ichi TOYAMA <dol...@wm...>

[Tuxpaint-i18n] Per-locale default font

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

For a long while now, Tux Paint has used "DejaVu Sans" as the
preferred font for the UI (requested via Pango, though based on what I
see in screenshots on Twitter, some folks don't have that font and
some alternatives are used).

Recently, Shin-ichi noted that we have a font tucked away in
"fonts/locale/" that looks much better for use with Japanese text,
but we're not using it (we no longer load TTF files directly and use
SDL_ttf to render strings, it's all SDL2_Pango now).

Therefore, I've added the ability for us (the Tux Paint developers)
to specify a preferred font on a per-locale basis.  It's simply
a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
describing the font family we want Pango to load.
(If left unspecified, we'll continue to ask for "DejaVu Sans".)

This is now in the Git master branch over in the SourceForge project,
and will be part of Tux Paint 0.9.31.

I'm about to try to set fonts, as best I can, based on the collection
of TTF files we have been shipping with Tux Paint.  Those files seem
to be useless now, unless I'm mistaken!  However, I wonder if we could
install them into the system where Pango can find them, when installing
Tux Paint?  Or perhaps we could somehow point Pango to our directory
of locale fonts as an extra place to look when scanning for fonts...?

Thoughts?

And also, if you have a preferred font for your favorite locale,
please share and I can add it to the list!

-- 
-bill!
Sent from my computer

[Tuxpaint-i18n] Tux Paint 0.9.30 & friends beta builds available

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

The team (Mark, Pere, Shin-ichi) and I have put together beta builds of
Tux Paint 0.9.30, Tux Paint Config. 0.0.21, and a new Tux Paint Stamps,
using the current source-code snapshot from today (2023-05-14).

I'm going to have people in the wild test it, and provide feedback,
but am hopeful that within a few days we'll be able to release final
builds of these versions of the project's various parts.  So if you'd
like to get any last minute localization updates in, please send them
my way (or commit to the Git repos at SourceForge) as soon as possible!

If you want to try them out, I'm posting them to the Tux Paint
SourceForge project's "Files" section right now, and will be posting
a note to both tuxpaint-devel@ and tuxpaint-users@ mailing lists
about it once they're available for download.

Thanks in advance!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] Tux Paint 0.9.29 coming soon

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

On Sat, Apr 01, 2023 at 03:49:39PM +0200, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 28.03.2023 18:51:
> >We'll soon be releasing the final version of 0.9.29, so please
> >get translations sent in soon, so I can get them included.
> 
> I have a question about this string:
> 
>     The rainbow palette (HSV color picker) can now load the built-in color,
>     or the colors from the pipette tool or color mixer.
> 
> What is the ‘built-in color’?

Yeah that was hard to explain, sorry. :)  So think of classic Tux Paint
from many years ago, where the "Colors" section only contained a palette
of pre-defined colors.  It is these colors that I'm talking about.

That is as opposed to a user-chosen color, created by either using the
pipette tool to pull the color from the canvas, or the color mixer
(mix combinations of red/yellow/blue/black/grey/white), or even the
rainbow palette itself. [*]

[*] The rainbow palette came first, IIRC, and was initially just
a square containing approx. 65,000 colors to choose from.  Recently
I added the separate luminance/value bar, to allow for approx.
16,000,000 colors to choose from, making it a kind of HSV picker.


PS - I just added a new ".desktop" launcher for Freedesktop.org
(Linux, etc.) which runs Tux Paint in fullscreen mode (like we have
had for Windows for a while), which adds one new string to the POT
and PO files: "Tux Paint (Fullscreen)".  Sorry for the late addition!

-bill!

Re: [Tuxpaint-i18n] Tux Paint 0.9.29 coming soon

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

Bill Kendrick skreiv 28.03.2023 18:51:
> We'll soon be releasing the final version of 0.9.29, so please
> get translations sent in soon, so I can get them included.

I have a question about this string:

     The rainbow palette (HSV color picker) can now load the built-in color,
     or the colors from the pipette tool or color mixer.

What is the ‘built-in color’?


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-i18n] Tux Paint 0.9.29 coming soon

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

Beta versions of Tux Paint 0.9.29 are now available for
Windows, macOS, Android, RHEL Linux, and Haiku, for those
who want to poke around and see what's new.

We'll soon be releasing the final version of 0.9.29, so please
get translations sent in soon, so I can get them included.

I think 0.9.30 will be close on the heels of this version, as
I have a few Big Ideas (tm) that I wanted to work on... but I didn't
want to hold up the current release, since there's so much new
stuff in it already.  (I keep teasing glimpses of it on social media,
and our followers were champing at the bit to get ahold of the new
features. ;-) )

Thanks in advance,

-bill!
PS - I may take a moment to email localization contributors
personally, since I don't actually know how many are subscribed
to this list (and SourceForge's mailing list system makes it
impossible for anyone -- even project admins -- to actually see
who is subscribed :-( ).  So apologies if you hear from me again;
I don't mean to nag.  I just don't want anyone to miss out. :-)

On Sun, Mar 12, 2023 at 09:55:10PM -0700, Bill Kendrick wrote:
> 
> Some time later this week I hope to release a beta version of Tux Paint
> 0.9.29 so Shin-Ichi, Mark, and Pere can build binary versions for
> Windows, Linux, macOS, and Android.
> 
> A few tools have been updated, and a lot of new Magic tools have been
> added since 0.9.28 was release last June.  Documentation covering the
> new features has been added to README, OPTIONS, and even EXTENDING.
> I've also create a new quick-start guide (mentioned in a previous
> thread on this list).
> 
> So if you'd like to get translation updates in Tux Paint 0.9.29,
> please get them to me soon.  For those of you who rely on binary
> builds, you'll have an opportunity to try the new features out via the
> set of beta builds we're making, and then get your final PO updates to
> me prior to the final release of 0.9.29.
> 
> As a reminder, you can fetch the POT and PO files from the Git code
> repositories in the Tux Paint project at SourceForge, or from this
> page on the website:  https://tuxpaint.org/help/po/
> (The web page is not instantaneously/automatically updated, but I try
> to keep it sync'd up with what's in Git at least once a day-ish.)
> 
>  * The "tuxpaint" repo contains the main program & stamps.
> 
>  * The "tuxpaint-docs" repo contains the end-user documentation.
> 
>  * The "tuxpaint-config" repo contains the configuration GUI for
>    parents/guardians/teachers.
> 
>  * And the "tuxpaint-stamps" repo contains the stamp collection.
>    (Nothing new has been added since the June 2022 release,
>    in terms of translatable strings.)
> 
> Finally, the website is always being worked on, and you can get
> translation updates to me at any time.  See "tuxpaint-website"; there
> are two sets of POT & PO files -- high-priority (important pages) and
> low-priority (non-essential pages).
> 
> I'd prefer folks post their changes directly to the Git repo.
> If you have a SourceForge account and are not part of the
> "tuxpaint" project, let me know and I can add you!
> 
> Next best is to fork the project and make a Pull Request (PR),
> which I can review & merge.
> 
> Worst-case scenario, you can email me your PO files directly.
> 
> 
> Thanks very much in advance!  I hope everyone out here on this
> list is staying well.
> 
> -- 
> -bill!
> Sent from my computer

-- 
-bill!
Sent from my computer

[Tuxpaint-i18n] Tux Paint 0.9.29 coming soon

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

Some time later this week I hope to release a beta version of Tux Paint
0.9.29 so Shin-Ichi, Mark, and Pere can build binary versions for
Windows, Linux, macOS, and Android.

A few tools have been updated, and a lot of new Magic tools have been
added since 0.9.28 was release last June.  Documentation covering the
new features has been added to README, OPTIONS, and even EXTENDING.
I've also create a new quick-start guide (mentioned in a previous
thread on this list).

So if you'd like to get translation updates in Tux Paint 0.9.29,
please get them to me soon.  For those of you who rely on binary
builds, you'll have an opportunity to try the new features out via the
set of beta builds we're making, and then get your final PO updates to
me prior to the final release of 0.9.29.

As a reminder, you can fetch the POT and PO files from the Git code
repositories in the Tux Paint project at SourceForge, or from this
page on the website:  https://tuxpaint.org/help/po/
(The web page is not instantaneously/automatically updated, but I try
to keep it sync'd up with what's in Git at least once a day-ish.)

 * The "tuxpaint" repo contains the main program & stamps.

 * The "tuxpaint-docs" repo contains the end-user documentation.

 * The "tuxpaint-config" repo contains the configuration GUI for
   parents/guardians/teachers.

 * And the "tuxpaint-stamps" repo contains the stamp collection.
   (Nothing new has been added since the June 2022 release,
   in terms of translatable strings.)

Finally, the website is always being worked on, and you can get
translation updates to me at any time.  See "tuxpaint-website"; there
are two sets of POT & PO files -- high-priority (important pages) and
low-priority (non-essential pages).

I'd prefer folks post their changes directly to the Git repo.
If you have a SourceForge account and are not part of the
"tuxpaint" project, let me know and I can add you!

Next best is to fork the project and make a Pull Request (PR),
which I can review & merge.

Worst-case scenario, you can email me your PO files directly.


Thanks very much in advance!  I hope everyone out here on this
list is staying well.

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] Confused by font scoring strings

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

Hi Karl,

El dg. 26 de 02 de 2023 a les 15:36 +0100, en/na Karl Ove Hufthammer va escriure:
> Hi!
> I’m confused by the four new font scoring strings. The extracted comment says:
>  
> > If neccessary, translate any of following strings using at least
> > two locale specific characters required to render your language.
> > Then, the scores for those fonts having such characters will increase.
> > You can use two different weight for scoring, 1 or 9, according
> > to the importance.
> And the strings are:
>  
> > <1>spare-1a <1>spare-1b <9>spare-9a <9>spare-9b
> Which parts of the strings should I translate? 

You should replace the whole string  by chars needed in your language.
Or just 2 identical chars if you are happy with the scores of the other font quality checks. 


> Should I just append two (or more) characters:
>  
> > <1>spare-1aæø <1>spare-1bæø <9>spare-9aæø <9>spare-9bæø

No, that lets 2 identical chars in each string('1' or '9') and the check will fail.


> Or should I replace the entire strings? 

Yes, if needed by the language.


> Does the numbers (the ones on start of each string and/or the ones on the end) signify anything?

Yes, they match the weight the string has in the font scoring process,
the '1' strings wheight 1 point, the '9' strings wheight 9 points.


>  Can I change them?

Yes, you can put there any string that reflects the needs of your language, 
but the wheight will not change, they will continue to  be of 1 and 9 points


>  What is the difference between ‘a’ strings and ‘b’ strings? 

'a' and 'b' strings are there to leave translators the option to use 2 strings for 1 point and 2 for 9 points.
They are independent, if one of the '1' strings fails, the other can sum if it passes.
Same for the '9' ones


> Why are there four different strings? 

Depending on the language requirements you may need 0 to 4 of those strings.
If you are fine with the font scoring provided by the other translations, then you don't need any of the spare strings.

You could use the '9' strings to give the fonts that passes their tests  a very high score, 9 + 9
ensuring that those fonts will end up in the first position despite other tests.

This may allow to not need to use the blacklisting "QX" "qx" strings but still get a high punctuation 
to the fonts suitable in a language, allowing fonts for other languages be available more down the list.


> What should I (not) put into them?

If you want some of those tests count in the font score wheigthing, you must not put two (2) identical chars in them.

If you don't need some of those tests, you must put two (2) identical chars there.
Note that by default they contain already two identical chars each of them, so leaving them untranslated is safe if you don't need them.


The tests work as this, IIRC:
render each of the chars of the string and compare to each other, 
if a char fails to render, then the test fail.
if one char renders as a square/rectangle but renders anyway, the test doesn't fail (still). 
if a char renders identical as another char(example 2 chars rendering as squares/rectangles), then the test fail

So many fonts replace missing chars by rectangles instead of simply not rendering, so to catch them you need to make the font render 2 rectangles


See also the thread at
https://sourceforge.net/p/tuxpaint/mailman/tuxpaint-devel/thread/20221217110312.c9b6e27cb0349790aaac288c%40wmail.plala.or.jp/#msg37749918



HTH
Pere

[Tuxpaint-i18n] Confused by font scoring strings

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

Hi!

I’m confused by the four new font scoring strings. The extracted comment 
says:

    If neccessary, translate any of following strings using at least

    two locale specific characters required to render your language.
    Then, the scores for those fonts having such characters will
    increase. You can use two different weight for scoring, 1 or 9,
    according to the importance.

And the strings are:

    <1>spare-1a <1>spare-1b <9>spare-9a <9>spare-9b

Which parts of the strings should I translate? Should I just append two 
(or more) characters:

    <1>spare-1aæø <1>spare-1bæø <9>spare-9aæø <9>spare-9bæø

Or should I replace the entire strings? Does the numbers (the ones on 
start of each string and/or the ones on the end) signify anything? Can I 
change them? What is the difference between ‘a’ strings and ‘b’ strings? 
Why are there four different strings? What should I (not) put into them?

-- 
Karl Ove Hufthammer

Re: [Tuxpaint-i18n] Tux Paint Quickstart Guide added to tuxpaint-docs repository

[Shin-ichi T. <dol...@wm...>]

Hi!

I added checkbox to open the Quickstart Guide on Windows installer.
Currently, translations for French and Galician are enabled.

I will start working on Japanese translations.

Please let me know if other langs are ready.

On Wed, 2 Nov 2022 01:28:15 -0700, Bill Kendrick wrote:
>
>I've created a "quickstart guide" for Tux Paint that briefly explains
>the program's functionality in a terser and more compact way than the
>full README.
>
>My thought is, it could be something simple to hand to kids in
>a classroom when they first learn how to use Tux Paint, and could
>act as a reference.
>
>It's HTML which uses PHP + gettext to allow localization.
>The POT and PO files in the 'tuxpaint-docs' repo have been updated
>accordingly.
>
>There's more work I need to do, to pull out some keypress strings
>(e.g., "[Ctrl]", "[Esc]", etc.), so it's still a bit of a moving
>target.  I wanted to give everyone a heads-up about it before
>I forgot, though. :)
>
>On my Linux laptop running Chrome, it looks like this doc would
>print out to 4 pages of US Letter paper.  It's about 1,250 words.
>
>Thanks!
>


-- 
Shin-ichi TOYAMA <dol...@wm...>

[Tuxpaint-i18n] Tux Paint Quickstart Guide added to tuxpaint-docs repository

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

I've created a "quickstart guide" for Tux Paint that briefly explains
the program's functionality in a terser and more compact way than the
full README.

My thought is, it could be something simple to hand to kids in
a classroom when they first learn how to use Tux Paint, and could
act as a reference.

It's HTML which uses PHP + gettext to allow localization.
The POT and PO files in the 'tuxpaint-docs' repo have been updated
accordingly.

There's more work I need to do, to pull out some keypress strings
(e.g., "[Ctrl]", "[Esc]", etc.), so it's still a bit of a moving
target.  I wanted to give everyone a heads-up about it before
I forgot, though. :)

On my Linux laptop running Chrome, it looks like this doc would
print out to 4 pages of US Letter paper.  It's about 1,250 words.

Thanks!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] Magic API development docs migrated to `tuxpaint-docs` repo; supports l10n

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

On Tue, Oct 04, 2022 at 02:52:21AM -0700, Bill Kendrick wrote:
> 
> The documentation that explains to developers how to use
> the Tux Paint Magic tool API to write new effects has been
> migrated from the 'tuxpaint' repo -- where it was a hand-coded
> HTML file in English -- to 'tuxpaint-docs' -- where it is
> a PHP-based HTML file with strings wrapped in gettext().
<snip>


I have begun doing the same to the example C source file that ships
alongside Tux Paint's Magic API documentation, "tp_magic_example.c".

That is, once I'm all done, and if anyone out here is crazy enough to
bother localizing the strings that are being added to the Magic API
docs POT files, things like code comments, strings (tool names and
descriptions), and even variable names ("canvas", "snapshot", etc.)
may be localized.  (For the latter you'll want to limit yourself to
valid variable names in the C language, which means no spaces or
punctuation other than underscore... and I'm actually not sure whether
non-ASCII characters, such as "�", are valid...!?)

It's still a work-in-progress.  It's basically a PHP file with
<?= gettext() ?> (sometimes inside an sprintf(), which is also
sometimes inside a wordwrap()) around the relevant bits, like so:

  ...
  /*
  <?= wordwrap(sprintf(gettext("Here is a comment on how to use the %s function"), "foo()")) ?>
  */
  void foo() {
    <?php $my_local_var = gettext("my_local_variable"); /* e.g. in Spanish "mi_variable_local"...? */ ?>
    int <?= $my_local_var ?>;

    for (<?= $my_local_var ?> = 0; <?= $my_local_var ?> < 10; <?= $my_local_var ?>++) {
      ...
    }
  }

which would render in the final C file as (in the English version):

/*
Here is a comment on how to use the foo() function
*/
void foo()
  int my_local_variable;

  for (my_local_variable = 0; my_local_variable < 10; my_local_variable++) {
    ...
  }
}


And perhaps in Spanish, it might be:

/*
Aqu� hay un comentario sobre c�mo usar la funci�n foo()
*/
void foo()
  int mi_variable_local;

  for (mi_variable_local = 0; mi_variable_local < 10; mi_variable_local++) {
    ...
  }
}


More madness, I know... but I figure if the API documentation can be
localized, there's no reason to suddenly require English comprehension
just to see a small example C file.

(There's already plenty of English baked into programming languages like C.
"void", "float", "int"eger, "print[f]", etc. :) )

-bill!

Re: [Tuxpaint-i18n] Magic API development docs migrated to `tuxpaint-docs` repo; supports l10n

[Sveinn í F. <sv...@fe...>]

Þann 4.10.2022 09:52, skrifaði Bill Kendrick:
 >
> It's a lot of technical content, and I figured translators
> wouldn't appreciate seeing their PO file bloated with a
> bunch of text they might never want to bother localizing.

> 
> Thanks for your patience with me and my nonsense. ;-)
> 

Your nonsense is quite logical, sir... ;-)

best regards,
Sveinn í Felli

[Tuxpaint-i18n] Magic API development docs migrated to `tuxpaint-docs` repo; supports l10n

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

The documentation that explains to developers how to use
the Tux Paint Magic tool API to write new effects has been
migrated from the 'tuxpaint' repo -- where it was a hand-coded
HTML file in English -- to 'tuxpaint-docs' -- where it is
a PHP-based HTML file with strings wrapped in gettext().

It's a lot of technical content, and I figured translators
wouldn't appreciate seeing their PO file bloated with a
bunch of text they might never want to bother localizing.

Therefore, I've rigged things up in the 'tuxpaint-docs'
repo to create & maintain separate POT & PO files for
this one new document ("MAGIC-API"), leaving the main
POT & PO files (for all of the other user docs:
"README", "OPTIONS", etc.) untouched.

I have NOT yet updated my PO Stats updating system, or
added reference to the new MAGIC-API-related POT/PO
files to the website.  It's about 3am and I'm about
3 hours late getting to bed. :-)

Hopefully I can work on doing that later this week.
In the meantime, if anyone wants to take a peek,
you can of course see these files in the Git repo:

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

(the files named "...-magic-api.xxx")

Thanks for your patience with me and my nonsense. ;-)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-i18n] Stamp rotation feature -- translation needed

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

On Sat, Sep 10, 2022 at 03:57:40PM +0200, Jacques Chion wrote:
> Le 07/09/2022 à 21:01, Bill Kendrick a écrit :
> >
> >Pere added a rotation step to the "Stamps" tool, and therefore the UI,
> >documentation, Tux Paint Config, and the website have all had some
> >updates to reflect this.
> >
> >The POT and PO files for these various parts of the project have been
> >updated, so if you'd like to translate the relevant strings, please
> >do so!
> >
> 
> I am updating the different translations in french.
> I have some problem with the word 'rush'. I see it is doing a kind
> of blur, but what is the right action of this magic tool ?

It's somewhat similar to GIMP's Blur -> Zoom Motion Blur.


> On a another hand, i compiled tuxpaint myself on ubuntu 22.04, and
> some magic thumbnails are only black rectangle (for example xor.png
> or mosaic.png). What could be the reason ?

Is this true with the latest in the `sdl2.0` branch?
I had optimized some PNGs and they were doing this
for me (IIRC they were solid white, not black, though).

I opened them in GIMP, made sure they were Greyscale mode,
and saved them back out.

Thanks,

-- 
-bill!
Sent from my computer