I18N: Add support for Polish

[zyga]

Hey

I translated all of the software into Polish. I will be sending separate patches soon. I ran into some issues with extra unicode characters. Those end up as garbage glyph blocks. I looked at the text drawing functions and I didn't find any shade of UTF-8 support so I assume those need to be mapped into the 8-bit blocks somehow. Am I missing anything? Any advice on how to fix that? I'll send my patches later today as they are on a separate machine.

[Ecco]

Hi @zyga, thanks a lot, we really appreciate it! Currently we only support a very small charset: essentially a-z, A-Z, 0-9.

Unfortunately I don't speak Polish so I don't know if it's possible to use this restricted charset.

The problem with a larger charset is that it takes adding extra glyphs quickly eat up a lot of memory…

[zyga]

Polish uses extended Latin characters, I had to added (AFAIR, again other laptop) 18 glyphs for both lower and upper case characters. Detailed analysis of my translation might uncover redundant positions that are not used.

I understand the memory issue (AFAIK the device has 1MB flash storage) but I think it's possible to either just fit it (I didn't try) or offer build variants. Lastly Polish can be "reduced" to just ASCII at some small eye sore so if anything we might land that variant.

BTW: I tried to open the font files that are in the project but those caused gnome font viewer to crash. How are you working with them?

The set of non-ASCII characters used by Polish is: ą, ę, ś, ć, ń, ź, ż, ł, ó

[zyga]

Arguably those could also (perhaps) be handled by composing Unicode characters. I could also try to patch the render functions to compress the fonts so that less ROM is necessary for them.

[adriweb]

To save space on strings/translations in general, I suppose additional languages (other than English and French?) could be downloaded separately? Or rather it would be an OS with only English+X, where X is the language chosen by the user on the OS update site.
This would probably save quite a lot of space, allowing for example for a much larger ASCII range (having the extended ascii range from 128 to 154, for instance, would be nice)

[zyga]

I was also thinking about compressing the strings. Given the amount of text we could do that on the fly (though probably compressing the fonts would yield more savings). Since I just ordered my device and I didn't try it can someone tell me how much space remains with the current master?

[Ecco]

Here are a couple things to know about text rendering:

• Glyph rasterization is done at build time. We embed bitmap version for every single glyph. This tends to eat up quite a lot of flash rather quickly.
• Text rendering can easily become a bottleneck in terms of display performances. Special attention should be paid to performance when dealing with text rendering, and testing should really be done on the device.
• There's 1MB of flash space on the device. Current firmware takes half of that (513k to be precise). Clearly it's definitely possible to embed a lot of extra characters but we thought it was better to save flash space for other features.

Maybe the best solution could be to use a tiered system? It would unfold as follow:

• Have a firmware flashed in factory with the "k" most-frequently used languages.
• Then have a custom firmware generated when the end user updates his/her device, specifically with his/her own language added in.

[boricj]

The glyphs are currently stored as uncompressed 8 bits per pixel masks.

Experiments with GIMP suggests they can be acceptably downsampled down to 3 bits per pixel. If keeping bit twiddling to a minimum is desired, a reasonable compromise would be 4 bits per pixels combined with a 4-bit variant of PackBits. You could probably quadruple the number of glyphs for the same Flash space usage with no practical performance loss.

[zyga]

Let's decouple this into two problems:

• landing the extra language support without the use of non-ascii characters
• exploring adding the extra 18 characters, perhaps with some of the other enhancements proposed above

[Ecco]

Great suggestion @boricj. We could indeed lower the pixel depth (bpp) of the mask. 4-bits might be a good idea given that text rendering is a hot path of code execution. Definitely something worth trying though.

And I think @zyga is right too, we need to split this issue in smaller sub-problems.

What do you guys think of:

1. Add a way to pick the set of localization built-in at compile-time.
2. Add an actual Polish translation
3. Consider adding more glyphs. Maybe make it play well with 1 too (i.e. don't embed glyphs that won't be used).

[Ecco]

Hi @zyga ! Once #174 will have landed (hopefully sooner rather than later) you'll be able to easily contribute a Polish translation :)

[zyga]

Thank you for letting me know :) I was just using the device without remembering to contribute back :)

[zyga]

Oh, it's merged now. I can propose my translation :)

[tvillingett]

I have made an Swedish translation also, should we make some kind of lang pack for general approach?