Created Korean Translations #1858
Conversation
|
Thanks so much! We're going to leave this open until we can support it. |
This fixes two additional problems, a missing newline and an incorrect character set definition. However, the build process still fails locally during "makeqstrdata"
It is possible for this routine to expand some inputs, and in fact it does for certan strings in the proposed Korean translation of CircuitPython (adafruit#1858). I did not determine what the maximum expansion is -- it's probably modest, like len()/7+2 bytes or something -- so I tried to just make enc[] an adequate over-allocation, and then ensured that all the strings in the proposed ko.po now worked. The worst actual expansion seems to be a string that goes from 65 UTF-8-encoded bytes to 68 compressed bytes (+4.6%). Only a few out of all strings are reported as non-compressed.
|
With #2042 in the mix, this DOES build a final .uf2, though 134 characters are missing from the bitmap font. Building circuitplayground_express, there are now |
|
@jepler We'll need to either rebase or merge it in. (I'm sure we'll need to rerun make translate too.) We both should be able to push to the original branch from our local git. If we can't, we can always make a new branch. |
On a Debian 10 system, the number of arguments to xargs was such that
it would not fit in a single invocation (xargs --show-limits prints
"bytes: Size of command buffer we are actually using: 131072").
In this situation, the output from the second invocation of xgettext
would replace the output of the first one, so messages that appeared only
in files early in the list would be lost. Strings in "extmod" were most
frequently the victim, including "incorrect padding" from modubinascii.c.
Unfortunately, when the github environment was similar enough to the
environment where "make translate" was invoked, the problem was not
found by "check-translate", because the same (incorrect, truncated)
potfile would be generated on both systems. Apparently Ubuntu and Debian
were different enough that the problem could become visible.
xgettext has a mode where it reads files from stdin ('-f-'), but this does
not have a zero-delimited variant documented. Still, we will assume
that files with adversarial names are not committed to circuitpython
or created by the build process, and print newline-delimited filenames
from `find` to be processed by `xgettext -f-`.
I manually inspected the changes relative to 5.0.0-alpha.5-93-g8778f367e and believe they are innocuous; Besides restoring some translations that had become fuzzy, "c-format" was removed from many (all?) fuzzy messages, and the word-wrapping of one message was changed.
|
Testing performed: built locally for metro m4 express, connected from unicode-capable terminal program, provoked an error: |
|
@tannewt can we get a fresh review from you? I think maybe this can go in, unless the missing font characters must be considered a blocker. |
|
We did consider the lack of glyphs to be a blocker, and adding glyphs could easily overflow the small builds. So I think we will continue to hold this open. |
|
Can we break this down into additional issues? Maybe:
|
|
@rafa-gould thanks for your work in this PR, I'm sorry technical limitations are making us slow to accept it. |
|
I'd rather merge this in and be ok with missing glyphs in the terminal. I was thinking we could later turn the terminal off for fonts that are too big to store (chinese). For Korean, we could probably just add the missing glyphs later. |
|
@tannewt I think we could do so if you give us an approving review. I'm loathe to do it since I tinkered so much in this PR. |
Will fail because of a lack of unicode support, however when unicode support is added it will work!
Thank you so much!