62832
Update zh_cn
This PR is set to draft for self-proofreading, and will be ready for review once that's finished.
I'll leave that responsibility to you then; I can't exactly proofread any of it since I'm not a Chinese speaker.
The PR has gone through proofreading, courtesy of @ZombieArchive. Check here for details on this. There may be more proofreadings to come.
Though there are still issues on translations (I haven't checked the code yet, please forgive me if the following issues seem dumb):
-
As in the PR above, L141-L144 in
bulk_cell.mdmentions that[...] Furthermore, for the purposes of error correction in the event that some variant smaller than the item configured onto the cell is added, removed or replaced, the current "unit factor" — i.e. how many "units" will fit in total into one instance of the configured "variant" item — is also stored and tracked, updating accordingly when the overall chain for these variants sees such a change.
The second bolded part be interpreted as either:
- changing the factored item would "unit factor" change accordingly, or
- storing/extracting items into/from cells would "unit factor" change accordingly.
While testing in-game, NBT tag
megacells:bulk_unit_factordoesn't see such changes when its factor configuration gets cleared, but it does change when adding or replacing with variants. The latter one is not likely since "replacing" variant items within cells makes no actual difference, and storing/extracting also wouldn't cause the NBT to change.If the former one is the intended meaning, the tests above sees changes in NBT in both directions, say, Iron Ingots (
"9") to Iron Nuggets ("1") and Ingots ("9") to Blocks ("81"). As such, the first bolded description only covers a subset of situations, is this especially made so, or is the aforementioned assumption false?
~~this is definitely some broken english above~~
I'd like to also apologize for the misconception I made in the last comment. I was only meant to say that this PR shouldn't be merged prematurely before proofreading, and I'm really sorry if it sounded like asking for or even demanding one.
The current translations treats the description mentioned in the last comment as modifying factor settings would cause such changes. "[...] some variant smaller [...]" part is left out since this behavior restriction isn't seen in-game as well as in code (if I read correctly tho).
Pic link at L115 (assets/diagrams/bulk_cell_compressed_2.png) in the same file may be flawed, this leads to a pic not being used anywhere in Guide. This PR changes that link in _zh_cn to the not-used pic (assets/diagrams/bulk_cell_compressed_3.png), and is decided so purely through guesswork.
@ChuijkYahus Thank you for your effort so far, I appreciate how thorough you've been throughout.
While testing in-game, NBT tag
megacells:bulk_unit_factordoesn't see such changes when its factor configuration gets cleared, but it does change when adding or replacing with variants. The latter one is not likely since "replacing" variant items within cells makes no actual difference, and storing/extracting also wouldn't cause the NBT to change.If the former one is the intended meaning, the tests above sees changes in NBT in both directions, say, Iron Ingots ("9") to Iron Nuggets ("1") and Ingots ("9") to Blocks ("81"). As such, the first bolded description only covers a subset of situations, is this especially made so, or is the aforementioned assumption false?
I think my wording on that was initially too ambiguous; that excerpt you quoted was not referring to when the user adds or removes items from within the cell in game. Rather, it refers to the situation where the crafting recipes for some smaller variant happen to get removed or if further smaller variants come up based on any new crafting recipes, in the event that the server is either restarted or /reloaded.
Those recipes changing, without the error-correction measure in place, would mean that any "base unit" count would be incorrect if the actual unit variant becomes a different item or if other new variants are introduced in between. In that case, users would see a wildly different quantity of the item they were keeping track of and storing on that Bulk Cell, compared to the quantity that was previously reported based on the earlier set of crafting recipes on the server.
This should be OK to go by now. Further updates and fixes would belong to new PRs if they occur.
Good work overall. There is just one more thing I'd like to suggest, though, and it's really only to do with formatting/aesthetics more than anything.
I generally like to keep things consistent with regards to text wrapping, so you might notice that the English guide (and even most of the code itself for the mod) features line breaks such that every line is a maximum of 120 characters in length. This is a generally standard length for most Java development and tends to be indicated by IDEs such as IntelliJ with the guide you see below.
Unfortunately, this currently has to be done manually for guide pages, as I don't yet have the option to use any Markdown formatting from Spotless (without the ability to configure formatting rules/settings and not mess up things like the YAML front-matter). As I am not familiar with the Chinese language or any of its rules for writing in terms of where to break lines, I would like to leave that up to you in case my attempt ends up causing confusion to native speakers looking to examine the guide from within the overall code base rather than in-game.
Note that these line breaks do not affect how the guide is presented in-game, since the Markdown standard requires two newlines to indicate the start of a new paragraph, while explicitly-rendered line breaks are only done with the \ character or some other equivalent (e.g. the <br> HTML tag for GitHub-flavoured Markdown and other such extensions).
Most of the line breaks here are done with a slight respect to visual length, semantic meaning, line break rules on punctuations in Chinese, and lint in VSCode editor, definitely a flawed and overly random way of doing wrap. Hanzi (fullwidth) takes up 2 Latin characters' (halfwidth) space under most monospace fonts, this setup uses a maximum of roughly 60 hanzi, in a way of keeping visual widths more consistent.
Sorry for posting comment in merged PRs, but a hard line break would cause unwanted spaces appearing in Chinese text, where any actual space characters should be avoided.
In-game tests use GuideME 21.1.9, AE2 19.2.10, MEGACells 4.8.5, they are the latest versions on CurseForge as of the time posting this comment.
This could be fixed by removing hard line breaks though. I might post a new PR for the purpose soon.