Tedi/popravki2023 11 08 (#68)

* 22-10-26

* Update src/error/result/enter_question_mark.md

* Update src/error/result/result_alias.md

* poprawki 2023-11-02

* std 1

* popravki

* Поправки 2023-11-07

* popravki 2023-11-08

---------

Co-authored-by: Красимир Беров <berov@cpan.org>

Author: teodosi

src/compatibility.md

@@ -1,5 +1,5 @@
 # Съвместимост
 
-Езикът Ръждьо се развива бързо и заради това могат да се появят някои
+Езикът Ръждьо се развива бързо, поради което могат да се появят някои
 затруднения със съвместимостта въпреки полаганите усилия за осигуряване на
 колкото се може повече бъдеща съвместитмост.

src/compatibility/raw_identifiers.md

@@ -8,9 +8,9 @@
 някоя библиотека, използваща по-старо издание на Ръждьо, има променлива или
 функция със същото име като въведената в някое по-ново издание.
 
-Например кошът `foo`, компилиран с изданието от 2015 г. изнася функция с име
-`try`. Тази дума е запазена за нова способност в изданието от 2018та. Без
-да ползваме сурови наименования няма начин да извикаме функцията.
+Например кошът `foo`, компилиран с изданието от 2015 г., изнася функция с име
+`try`. Тази дума е запазена за нова способност в изданието от 2018-та. Без
+да ползваме сурови наименования, няма начин да извикаме функцията.
 
 ```rust,ignore
 extern crate foo;

src/error/multiple_error_types/reenter_question_mark.md

@@ -1,7 +1,7 @@
 # Други ползвания на `?`
 
 Забележете, че в предния пример след разбора гледаме незабавно да сложим
-грешката в кутия:
+грешката от библиотеката в кутия:
 
 ```rust,ignore
 .and_then(|s| s.parse::<i32>())
@@ -66,13 +66,13 @@ fn main() {
 }
 ```
 
-Сега е доста по-чистичко. В сравнение с първоначалната `panic`-а, много
-наподобява на заместване на извикванията на `unwrap` с `?`, само дето типът за
-връщане е `Result`. И само трябва да бъдат разложени при получване от извикващия.
+Сега е доста по-чистичко. В сравнение с първоначалната `panic`-а, това много
+наподобява на заместване на извикванията на `unwrap` със `?`, само дето типът за
+връщане е `Result`. И сега само трябва да бъдат разложени при получване от извикващия.
 
 ### Вижте също:
 
-[`From::from`][from] and [`?`][q_mark]
+[`From::from`][from] и [`?`][q_mark]
 
 [from]: https://doc.rust-lang.org/std/convert/trait.From.html
 [q_mark]: https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator

src/meta.md

@@ -12,7 +12,7 @@
 ## Б. пр.
 
 [^meta]: отвъд, след, мета – meta. Заглавието на английски е „Meta”. Ако се
-  опитаме да разтълкуваме значението на тази дума като потърсим назад в
+  опитаме да разтълкуваме значението на тази дума, като потърсим назад в
   миналото, ще открием, че тази дума може да означава много неща.
   Най-подходящият превод в случая е като опишем за какво става въпрос.
   Значенията могат да бъдат: след, зад, между, сред, над, отвъд. Вижте

src/meta/doc.md

@@ -2,16 +2,16 @@
 
 Ползвайте `cargo doc`, за да изградите документация в `target/doc`.
 
-Ползвайте `cargo test`, за да изпълните всички тестове (включително тези от
-документацията), а `cargo test --doc` само за документалните тестове.
+Ползвайте `cargo test`, за да пуснете всички тестове (включително тези от
+документацията), а `cargo test --doc` – само за документните тестове.
 
 Тези команди ще извикат съответно `rustdoc` (и `rustc`) според необходимостта.
 
-## Документални коментари
+## Документни коментари
 
-Документалните коментари са много полезни за големи проекти. Когато изпълним
+Документните коментари са много полезни за големи проекти. Когато пуснем
 `rustdoc`, тези коментари се компилират като документация. Те се означават с
-`///`, и биват разбрани като [Markdown].
+`///` и биват разбрани като [Markdown].
 
 ````rust,editable,ignore
 #![crate_name = "doc"]
@@ -23,7 +23,7 @@ pub struct Person {
 }
 
 impl Person {
-    /// Връша личност с даденото ѝ име.
+    /// Връща личност с даденото ѝ име.
     ///
     /// # Аргументи
     ///
@@ -58,22 +58,22 @@ fn main() {
 }
 ````
 
-За да изпълните тестовете, първо изградете кода като библиотека, после кажете
+За да пуснете тестовете, първо изградете кода като библиотека, после кажете
 на `rustdoc` къде да намери библиотеката, така че да може да я свърже с всеки
-документален тест:
+документен тест:
 
 ```shell
 $ rustc doc.rs --crate-type lib
 $ rustdoc --test --extern doc="libdoc.rlib" doc.rs
 ```
 
-## Документални атрибути
+## Документни атрибути
 
 Следват няколко примера с най-използваните аргументи за атрибута `#[doc]`.
 
 ### `inline`
 
-Използва се за вместване на документацията вместо да се прави връзка към
+Използва се за вместване на документацията, вместо да се прави връзка към
 отделна страница.
 
 ```rust,ignore
@@ -82,14 +82,14 @@ pub use bar::Bar;
 
 /// документация за bar
 mod bar {
-    /// Документацияе за  Bar
+    /// документацията за Bar
     pub struct Bar;
 }
 ```
 
 ### `no_inline`
 
-Използва се за да предотврати свързване към отделна страница или където и да е.
+Използва се, за да предотврати свързване към отделна страница или където и да е.
 
 ```rust,ignore
 // Example from libcore/prelude
@@ -107,14 +107,14 @@ pub use crate::mem::drop;
 pub use self::async_await::*;
 ```
 
-`rustdoc` се използва широко от обшността. С тази програма е създадена
+`rustdoc` се използва широко от общността. С тази програма е създадена
 [документацията за стандартната библиотека](https://doc.rust-lang.org/std/).
 
 ### Вижте също:
 
-- [Книгата за Ръждьо: Как да правим полезни документални коментари][book]
+- [Книгата за Ръждьо: Как да правим полезни документни коментари][book]
 - [Книгата за rustdoc][rustdoc-book]
-- [Справочникът: Документални коментари][ref-comments]
+- [Справочникът: Документни коментари][ref-comments]
 - [RFC 1574: API Documentation Conventions][api-conv]
 - [RFC 1946: Relative links to other items from doc comments (intra-rustdoc links)][intra-links]
 - [Има ли някакво ръководство за коментари? (reddit)][reddit]

src/testing.md

@@ -6,7 +6,7 @@
 Тестването се проявява в три разновидности:
 
 * [Поединично][unit][^unit] тестване (тестване на единици програмен код).
-* [Документално][doc] тестване (тестове в документацията).
+* [Документно][doc] тестване (тестове в документацията).
 * Тестване при [внедряване][integration][^integration].
 
 Освен това Ръждьо поддържа указване на зависимости по време на
@@ -25,8 +25,8 @@
 
 ## See Also
 
-* [„Книгата”][doc-testing] главата за тестване
-* [Съвети за добро ППВ][doc-nursery] за тестването на документация
+* Главата за тестване в [„Книгата”][doc-testing]
+* [Насоки за добро ППВ][doc-nursery] за тестването на документация
 
 [unit]: testing/unit_testing.md
 [doc]: testing/doc_testing.md

src/testing/dev_dependencies.md

@@ -1,13 +1,13 @@
 # Зависимости при разработка 
 
-Понякога ни трябват зависимости само за тестове или примери, или проверка на
+Понякога ни трябват зависимости само за тестове или примери, или за проверка на
 бързодействието. Такива зависимости се добавят в `Cargo.toml` в раздел
 [dev-dependencies]. Тези зависимости не биват предадени на други пакети, които
 зависят от този пакет.
 
 Един такъв пример е
 [`pretty_assertions`](https://docs.rs/pretty_assertions/1.0.0/pretty_assertions/index.html),
-който разширява стандартния `assert_eq!` и `assert_ne!` macros, да предоставя
+който разширява стандартните макроси `assert_eq!` и `assert_ne!`, за да предостави
 разноцветни разлики.  
 
 Файл `Cargo.toml`:

src/testing/doc_testing.md

@@ -1,9 +1,9 @@
 # Тестове в документацията
 
 Главният начин да се документира проект в Ръждьо е чрез добавяне на бележки в
-изходния код. Документалните коментари се пишат според [Спецификацията на
+изходния код. Документните коментари се пишат според [Спецификацията на
 CommonMark Markdown][commonmark] и поддържат блокове от код в тях. Ръждьо се
-грижи за правилността, така че тези блокове от код се компилират и ползват като
+грижи за правилността, така че тези блокове от код се компилират и се ползват като
 тестове от документацията.
 
 ```rust,ignore
@@ -21,7 +21,7 @@ pub fn add(a: i32, b: i32) -> i32 {
     a + b
 }
 
-/// Обикновено документалните коментари може да включват раздели „Examples”,
+/// Обикновено документните коментари може да включват раздели „Examples”,
 /// „Panics” и „Failures”.
 ///
 /// Следващата функция дели едно число на друго.
@@ -50,7 +50,7 @@ pub fn div(a: i32, b: i32) -> i32 {
 }
 ```
 
-Блоковете код в документацията биват тествани автоматично, щом изпълните
+Блоковете код в документацията биват тествани автоматично, щом пуснете
 командата `cargo test`:
 
 ```shell
@@ -71,20 +71,20 @@ test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
 
 ## Основания за тестове в документацията
 
-Главната цел на документалните тестове е да служат като примери, които ползват
-предоставяната функционалност, а това е най-важното
-[ръководство][question-instead-of-unwrap]. То ни позволява да ползваме примерите
+Главната цел на документните тестове е да служат като примери, които ползват
+предоставяната функционалност, а това са най-важните
+[насоки][question-instead-of-unwrap]. Те ни позволяват да ползваме примерите
 от документацията като пълноценни парчета код. Но ползването на `?` прави така,
 че компилацията се проваля, понеже `main` връща `unit`. В този случай можем да
-скрием няколко реда код от документацията: Можем да напишем `fn try_main() ->
+скрием няколко реда код от документацията: можем да напишем `fn try_main() ->
 Result<(), ErrorType>`, да я скрием и разгърнем (`unwrap`) в скритата `main`.
 Сложно ли звучи? Ето пример:
 
 ```rust,ignore
-/// Използване на скрита `try_main` в документални тестове.
+/// Използване на скрита `try_main` в документни тестове.
 ///
 /// ```
-/// # // Скритите редове започват със знака `#` но са също компилируеми!
+/// # // Скритите редове започват със знака `#`, но са също компилируеми!
 /// # // Ред, който обгръща тялото, показано в документацията.
 /// # fn try_main() -> Result<(), String> {
 /// let res = doccomments::try_div(10, 2)?;
@@ -108,7 +108,7 @@ pub fn try_div(a: i32, b: i32) -> Result<i32, String> {
 ## See Also
 
 * [RFC505][RFC505] за стила на документацията;
-* [API Guidelines][doc-nursery] За насоки при документиране.
+* [API Guidelines][doc-nursery] за насоки при документиране.
 
 [doc-nursery]: https://rust-lang-nursery.github.io/api-guidelines/documentation.html
 [commonmark]: https://commonmark.org/

src/testing/integration_testing.md

@@ -2,7 +2,7 @@
 
 [Поединичните тестове][unit] тестват всеки модул поотделно. Те са малки и могат
 да тестват частен код. Тестовете при внедряване са външни за коша ви и ползват
-само общодостъпната му външност, както всеки друг код би го ползвал.
+само общодостъпната му външност по същия начин, както и всеки друг код.
 Тяхното предназначение е да проверят дали различните части на библиотеката ви
 работят правилно заедно.
 
@@ -50,7 +50,7 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
 
 Всеки файл с изходен код на Ръждьо в директорията `tests` бива компилиран като
 отделен кош. За да ползваме общ код в различните тестове, можем да направим
-модул с общодостъпни функции, да внесем и ползваме в тестовете.
+модул с общодостъпни функции, да го внесем и ползваме в тестовете.
 
 Файл `tests/common/mod.rs`:
 
@@ -75,9 +75,9 @@ fn test_add() {
 }
 ```
 
-Ако създадем модула като `tests/common.rs` също ще работи, но не се препоръчва,
-защото изпълнителят на тестове смята файла за тестов кош и ще се опита да
-изпълни тестове в него.
+Също ще работи и ако създадем модула като `tests/common.rs`, но не се препоръчва,
+защото пускът на тестове смята файла за тестов кош и ще се опита да
+пусне тестове в него.
 
 [unit]: unit_testing.md
 [mod]: ../mod.md