es: fix some problems with the Spanish translation #1333
Conversation
|
Awesome, thanks @Phosphorus-M! I think this fixes #1328? Perhaps also #1329? |
| @@ -289,7 +289,7 @@ msgstr "Manejo de la Memoria en Rust" | |||
|
|
|||
| #: src/SUMMARY.md:88 src/ownership.md:1 | |||
| msgid "Ownership" | |||
| msgstr "Propiedad (_Ownership_)" | |||
| msgstr "Ownership" | |||
There was a problem hiding this comment.
We had a very in depth discussion at #1184 , and not sure that we had full consensus, but I think we pretty much came up with translated_msg (_english_msg_)
If this is a formatting concern due to the underscore, should we just use translated_msg (english_msg) instead?
There was a problem hiding this comment.
I don't oppose the idea of translating certain terms, as it's a topic of discussion in some Discord and Telegram channels. Many individuals support the notion of retaining the original English term, but it doesn't hurt to include a translated alias.
I concur with this perspective because it provides an additional means for users to grasp the terminology. For those who are not well-versed in English, comprehending the terms can be challenging.
In this case:
We employ the term "Ownership" but provide a note stating that "Propiedad" is an acceptable alternative for conveying the same concept.
I intend to revert this change in order to maintain both options.
There was a problem hiding this comment.
For the menus I would be fine by removing the Spanish translation, as it might look cluttered.
There was a problem hiding this comment.
The underscores are a problem here, as mentioned in #1328. So they should go for sure.
There was a problem hiding this comment.
Actually, you can keep the formatting! I'm working on making it look correct in google/mdbook-i18n-helpers#100. It should be merged in a few days and then formatting becomes file in the summary file.
| @@ -467,7 +467,7 @@ msgstr "Métodos por Default" | |||
|
|
|||
| #: src/SUMMARY.md:143 src/traits/trait-bounds.md:1 | |||
| msgid "Trait Bounds" | |||
| msgstr "Límites Trait (Bounds)" | |||
| msgstr "Trait Bounds" | |||
There was a problem hiding this comment.
Límites de Traits (Trait Bounds)
| @@ -3275,7 +3275,7 @@ msgid "" | |||
| "starting index, meaning that `&a[0..a.len()]` and `&a[..a.len()]` are " | |||
| "identical." | |||
| msgstr "" | |||
| "Si el slice comienza en el índice 0, la sintaxis de intervalo de Rust nos " | |||
| "Si el slice comienza en el índice 0, la sintaxis de rango de Rust nos " | |||
There was a problem hiding this comment.
I don't agree with this suggestion. "rango" can mean rank, which is very misleading here. "intervalo" is unambiguous
There was a problem hiding this comment.
Yesterday, @ph4un00b and I discussed this. "Intervalo" isn't a poor translation, it's akin to "time interval" and offers a more precise definition, especially for those with a mathematical background. However, for the majority of people, using terms like "rangos" when referring to range types is more commonplace.
Some examples of that:
Python
Ruby
Swift
Even when we're discussing Rust, we use the term "rango"
FreecodeCamp Tutorial
There was a problem hiding this comment.
I like it either way. Intervalo and rango works in this context for me.
There was a problem hiding this comment.
@Phosphorus-M, can you take out the translation here for now? Then try to reach a consensus with @JaviSorribes and the other reviewers and members of the Spanish Rust community.
Basically, I would love to merge this since it removes the weird-looking _foo_ words from the TOC. So if you could take out the translation here, then we can make forward progress. The translation can still go in, it should just be discussed in a smaller and more targeted PR.
There was a problem hiding this comment.
Hi all, please come to a conclusion here so we can merge this — I know it's hard to edit a large body of text like this, so I suggest taking out the change for now.
There was a problem hiding this comment.
Overall I have no issue with the changes in this PR. I would approve but I'd like to discuss with @JaviSorribes before doing so.
| @@ -289,7 +289,7 @@ msgstr "Manejo de la Memoria en Rust" | |||
|
|
|||
| #: src/SUMMARY.md:88 src/ownership.md:1 | |||
| msgid "Ownership" | |||
| msgstr "Propiedad (_Ownership_)" | |||
| msgstr "Ownership" | |||
There was a problem hiding this comment.
For the menus I would be fine by removing the Spanish translation, as it might look cluttered.
| @@ -3275,7 +3275,7 @@ msgid "" | |||
| "starting index, meaning that `&a[0..a.len()]` and `&a[..a.len()]` are " | |||
| "identical." | |||
| msgstr "" | |||
| "Si el slice comienza en el índice 0, la sintaxis de intervalo de Rust nos " | |||
| "Si el slice comienza en el índice 0, la sintaxis de rango de Rust nos " | |||
There was a problem hiding this comment.
I like it either way. Intervalo and rango works in this context for me.
| "Después de duplicar un dígito, se suman los dígitos que contiene. Por tanto, " | ||
| "si duplicas `7`, pasará a ser `14`, lo cual pasará a ser `5`." | ||
| "Después de duplicar un dígito, se suman los dígitos si el resultado es mayor " | ||
| "a 9. Por tanto, si duplicas `7`, pasará a ser `14`, lo cual pasará a ser `1 " |
There was a problem hiding this comment.
| "a 9. Por tanto, si duplicas `7`, pasará a ser `14`, lo cual pasará a ser `1 " | |
| "que 9. Por tanto, si duplicas `7`, pasará a ser `14`, lo cual pasará a ser `1 " |
mgeisler
changed the title
mgeisler
changed the title
|
Hi team, I'm ok with moving ahead with this PR if everyone else is in favor. Also, I'm going to step down from code reviewers. I'm sorry but I don't have the bandwidth and I feel like I'm slowing everyone else down. |
Thanks @JaviSorribes for your help! It's completely fine to leave comments like you did, it has to be a collaborative work to write a large translation like this. @deavid and @vzz1x2, can either of you review the PR and work on getting it merged? |
|
@mgeisler done. I reviewed this a week ago or so and I was already okay with it. I re-reviewed it again. I don't see anything wrong, so I merged it directly. I'm sure this PR improves way more than any possible mistake it could have, and if it does, we can always send another PR to fix any minor issues. |
|
@deavid, Im coming late to the party, but I agree with you, after reviewing it myself, it is much better having it than dont. |
Hi! I was checking the book and I found little things to fix.
I hope you review it.