Update Chinese translations for Snap! v12.1 - #3560
Conversation
I clean up the rest of the similar texts of translations from `LIBRARIES.json` and few libraries. This is the last update before the Zhongkao in Guizhou (June 20 to June 22) 我删除了`LIBRARIES.json`和部分库的类似内容。这是我参加贵州中考（6月20日至6月22日）前的最后一次更新
…ies to LIBRARIES.json
…and the true meanings I noticed that the "fill" and "close" label in draw path block , is easy to be confused with "填充" and "关闭" in Chinese translations. So I filled "?" after two labels to translate them exactly. I also added the new translations for 2 labels in lang-zh_CN.js.
I noticed that Jens (Snap! developer) created a new development version called 12.1.0, and imported "First-Class Processes" (A process can be passed as a data now, and can be merged freely by user) and Processes Library. They're too great to doubt because you can make the Snap! project faster by using them.
But I found a similar translating mistake from the library ("running"'s translation is confused with the same one in Embroidery Library). So I adjust it to divide them into different words, and to make translations more exact.
I also deal with the similar ones, adjust others, and insert "(翻译未覆盖)" label into descriptions of few libraries.
(p.s.: Jens is developing the version at the "dev" branch, not at the "master" branch. I must find a way to solve the sudden solution)
…uter Vision Library
This reverts commit a809226.
|
Thank you! This is great but also ... overwhelming. The problem with this pull request is that you've bundled a Chinese translation update with some structural changes inside the libraries themselves. I understand that these are mostly about adding a "$_" prefix to certain strings to make them translatable in the first place, but still, this requires me to 1) track the changes, 2) test them invidually and 3) check with all other translations. Another problem is that sometimes changing such a string or an input breaks the library elsewhere. I have tools that let me track that, but it takes enormous effort to apply them to an overwhelming multitude of proposed changes. Instead it would help me a lot if you could separate your pull-requests into a) mere translation updates - and again separate these into In general it would be better for me if you made smaller PRs that only affect one or three files at a time. That way I could, for example, pull your changes to the general localization file instantly, and it would go into the minor release coming up next week. The way it is now I first need to check everything before I either pull or reject your PR. I need to spend several days of work on this, and I don't have that time right now. So I will have to leave this open until well after the release, because I might only find the required time somewhere in October. Again, thank you so much. I am not rejecting this PR, but I need to put it off until I can muster a couple of days to work on it. [edit:] Oh, I just realized that I might have encouraged you to divide this PR up into dozens of smaller ones. Please don't, because that, too, would overwhelm me and probably delay the legitimate fixes. So, when you come across a string in a library that is untranslatable and would benefit from a translation prefix ("$_") what would really help me isn't a PR but if you opened an issue here that reports the library and block that you'd like to change, and you suggested change. It's totally fine if you bundle all your findings into a single issue, no need to file one per string. That way I can go through that list myself - as I will need to do anyway when I check a PR - and conduct these changes myself. That way I can make sure that nothing else breaks (and if it does anyway, the blame's on me ^^). Cheers! |
|
Thanks for the advice! I’ve realized that the PR is so huge and it’s in a mess since I read your comment. So I’m thinking about dealing with the huge PR now. I'm going to open a new issue to report the most necessary changes for Snap! v12.1 tomorrow. Because in China, some Scratchers also care about translation problems of Snap!, even though they prefer using TurboWarp (a popular Scratch mod) or its fantastic Chinese mods (02Engine, AstraEditor, etc.). The reason is also why I began to translate Snap! into Chinese from this year — Chinese Scratchers regard Snap! as a powerful editor by community, not as a very serious language for CS educations. So they support me in their hearts because I’m trying my best to make Chinese translations natural and friendly for Scratchers. (p.s.: It doesn't mean I'm a Chinese Scratcher now. Instead, I'm a Chinese Snapper that has a account at snap.berkeley.edu) |
This is the first commit to deal with PR jmoenig#3560. I'll opened a new PR that only contains itself.
2 participants
I must explain it carefully because it includes some important but might changes.
Changes
1. Translated the rest of libraries or so
By now, I finished a huge translations update for libraries again. These screenshots shows the result of this update:
Screenshots about the result
For libraries that are not translated yet or not translated completely, I labeled "（翻译未覆盖）" (It's not translated yet) or "（翻译未完全覆盖）" (It's not translated completely) into these descriptions.
2. Adjusted descriptions of 4 libraries which they're similar with Sennoma-Nn's problem
As the advice I mentioned in Sennoma-Nn's PR, I adjusted Chinese descriptions of "3D Beetle Geometry", "Words, sentences", "Just Words" and "Continuations" Library. Here are the descriptions now:
本自制积木库的原型是Snap!改版Bettle Blocks，因服务器数据丢失，导致其于Snap! 10作为自制积木库引入。
The library is made from Beetle Blocks (Snap! mod)'s new blocks. Because the server datas lost, It's introduced as a library in Snap! 10.
3. Adjusted options in some libraries, to avoid confusion with another meanings
Since I created the second PR at Snap! and it's merged, the Chinese translations has been different , fantastic and surprising (Especially, it's the first Chinese translation update for libraries). For translating them completely, I make a lot of drop-down menus' options translatable by inserting "$_" at the beginning of them.
But it also takes some problems about translations after I did it.
For example:
So I adjust the similar options, to avoid the solutions above, and to make translations more exactly. I also keep their values same to avoid breaking some projects (tl;dr: "$_option=value"). Including libraries below:
4. Others