Re: [Tuxpaint-devel] Font scoring method

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

Thank you again!

I noticed that there is a quite bad side effect in "ABC...xyz" approach 
that it overly score the fonts which render the string correctly if the 
string is not translated.

Then, I reverted dirwalk.c. Sorry for the mess.

By the way, I have not still understand well why the evaluation string 
are separated to some categories like 'cases', 'line-like' and so on.

Because of this, as pere pointed out, just adding Japanese characters to 
just one category may not push it on top, therfore, I suppose that I 
have to add them to multiple categories, if I want to see them on top.

In addition, I still feel a little unconfortable that there is no 
suitable existing category for Hiragana and Katakana, although I know it 
does not matter where to put them.

However, I will do what I have to do in the existing method so far.

Thanks.


On Sat, 17 Dec 2022 21:39:53 -0500, Albert Cahalan wrote:
>> I understand adding locale characters to the existing criteria works.
>>
>> However, I am a little at a loss where to put them, because;
>>
>>  * Japanese has no upper/lower cases distinction.
>>  * No common/special Japanese panctuations is used in Tux Paint.
>>  * Numbers are not different to those in ASCII.
>>  * It has no line-like/circle-like characters.
>>
>> In addition, I think it would be reasonable to give high priority to the
>> fonts supporting locale specific characters.
>>
>> I've pushed the change already, and would like to keep it if this has no
>> side effect.
>
>I would prefer the original design. It is not beneficial to have
>a second string that is redundant. This only makes the code
>more confusing for translators to use.
>
>In the original design, the only flaw I can see is that the
>intended usage was not documented very well.
>
>The entire reason to have the string be translated with gettext was
>to support languages like Japanese. It was meant for you to use.
>If there are now two strings, why would the original one need to be
>translated at all? This does not make sense.
>
>It doesn't matter that Japanese lacks uppercase/lowercase,
>has no line-like or circle-like characters, or shares numbers
>with ASCII. You should simply add Japanese characters.
>Leave the ASCII characters too, if it is at all reasonable for
>a Japanese person to use them.
>
>So to summarize proper usage:
>
>Add characters that matter, choosing a few that are most likely
>to be missing or indistinct. Remove any characters that have
>no value at all. Most likely, you add characters but do not remove
>any characters.
>
>My suggestion for Japanese specifically:
>
>Leave the ASCII. Add two katakana, two hirigana, and two kanji.
>Add the Yen symbol. Maybe add the Yuan symbol, in case there
>are fonts that unify them. If there exists a pair of characters that
>appear distinct in a good Japanese font but might be identical or
>missing in a Chinese or Korean font, be sure to add them.
>
>It is highly likely that multiple translators have make mistakes.
>Nearly all translations should retain the ASCII, adding a few
>new characters.
>
>For example, German should add:  ẞßβÖö€
>That prefers fonts that distinguish lowercase eszett
>from beta (a Greek letter) and uppercase eszett.
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


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