JavaScript Garden на русском языке — Готов! перевод

Молодцы

Ценное руководство, если всё там будет (или есть) доходчиво и без тумана.
Но вот что сразу заметил:

Единственный способ удалить свойство у объекта — использовать оператор delete;
устанавливая свойство в undefined или null, вы удаляете только связанное с ним значение, но не ключ.

Наверное, «Вы меняете», а не «Вы удаляете». (undefined или null — такое же равноправное значение, как строка, ссылка или объект)

При переводе нужно быть ооочень аккуратным, чтобы избежать не только стилитических ошибок вроде «двух очаровательных пользователей StackOverflow», но и смысловых ошибок:

Оригинал:
"[Prototypical inheritance] It is for example fairly trivial to build a classic model on top of it, while the other way around is a far more difficult task".

Перевод:
"[Прототипная модель наследования] К примеру, поверх неё можно предельно легко реализовать классическое наследование, а попытки обойти его при этом могут создать только трудности."

Хотя на самом деле смысл такой:
"[Прототипная модель наследования] К примеру, на ее основе достаточно легко построить классическую модель, в то время как обратная задача куда сложнее."

Важно отдавать себе отчет, понимаешь ли сам, что написано. Если не понимаешь — не надо браться. Если понимаешь, но предложение никак не клеится — объясни своими словами.

У вас там в одном месте используется:

{}.hasOwnProperty

Поправьте, пожалуйста!

({}).hasOwnProperty

var a = {}.hasOwnProperty;
a.call({a:1}, 'a');

При всем уважении к труду авторов, перевод технической документации на русский — самое бессмысленное в мире занятие. Воду в решете носить и то имеет больше смысла.

Поясню: программист не владеющий де-факто международным языком — плохой программист. Он вечно будет нуждаться в подобных переводах. Которые делаются с опозданием (если делаются вообще). Таким образом, прогресс нашего гипотетического одноязычного программиста сильно тормозится.

Кто не хочет учить английский — пусть идёт дисками на рынке торговать. Такое моё мнение.

Многие моменты освещены очень грубо, поверхностно, а местами — явно некорректно.
Например, почти сразу бросается в глаза фраза на shamansir.github.com/JavaScript-Garden/#object.general
«В JavaScript всё является объектом, лишь за двумя исключениями — null и undefined.», которая является весьма популярным заблуждением. В языке есть примитивы строк, чисел и булевых значений, и они не являются объектами ни в каком смысле, кроме того что определенные виды объектов могут образовываться из таких типов динамически, ради возможности вызова методов вроде 'abc'.toUpperCase().

Понимаю, что перевод, но надо ж смотреть, что переводишь.

var s1 = "abcdefg";
console.log(typeof s1); // "string"
s1.someProp = "abc";
console.log(s1.someProp); // undefined

var s2 = new String("abcdefg");
console.log(typeof s2); // "object"
s2.someProp = "abc";
console.log(s2.someProp); // "abc"

Огромное Вам спасибо!

Добавьте, пожалуйста, favicon на сайт. Очень уж некрасиво смотрится в Закладках без неё.

Сделал юзерстиль светлых тонов для этой чёрной страницы.

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document url("http://shamansir.github.com/JavaScript-Garden/") {

body{background: #fff!important; color: #000!important; font-family: Verdana, Helvetica, Arial!important}
nav a code,
.pun{color: #457!important;}
.typ,
.pln{color: #941!important;}
.lit{color: #457!important;}
.com{color: #494!important;}
.kwd{color: #622!important;}
.str{color: #666!important;}
section pre code,
code,
pre{background: #e6e6e6!important;}
pre{border-left: 2px solid #ccc!important;}
section pre code{border: 0!important;}
h2, h3{text-shadow: 0 0 0 #000!important}
article a{color: #c30!important;}
}

Не идеально, конечно, но читать можно.
(Подскажите, где есть готовая светлая цветовая схема?)

Спасибо всей команде, которая трудилась над русским огородом!
Очень порадовали.

Возможно я чего-то не понимаю, но стандарт ECMA явно указывает на существование примитивных типов: Undefined, Null, Numeric, String, Boolean, Object. И если иметь ввиду под словом «объект» Object, то тогда утверждение, что всё является объектом неверно.

Да, автоматическое заворачивание примитивного типа в объект никто не отменял.

Основная проблема с вашим переводом в том, что на русский язык переведены слова, но не предложения. Из за этого читать очень сложно — приходится продираться через текст не только в смысле понимания материала, но и в смысле понимания того, что там вообще написано. Первая часть текста переведена более менее нормально, вторая — хуже.

1. Хотя большинство из примеров ниже наполнены глубоким смыслом, первый из них можно считать ещё одним упущением в самом языке, поскольку он вообще не имеет практического применения. / Большинство из примеров ниже вполне жизнеспособны, однако первый следует считать ещё одним упущением в самом языке, поскольку он вообще не имеет практического применения.
2. Повторимся, это вообще не тот же самый эффект. Если вы не используете var — то вы в большой опасности. / Again, that is not at all the same effect, not using var can have major implications. – И еще раз – опуская var, вы создаете сильную путаницу, поскольку это не приводит к тому же самому результату.
3. Высасывание / Hosting – по смыслу «выталкивание»
4. Безымянные функции являются выражениями; поэтому, чтобы вы имели возможность их выполнить, они сперва должны быть разобраны / evaluated – вычислены. Или это специальный термин?
5. позваоляет создавать более модульные программы / «позваоляет» — опечатка / it also allows for better modularization of programs / позволяет лучше спланировать структуру кода
6. нет достаточных оснований для использования цикла for in для итерации по элементам массива. Фактически, существует несколько весомых причин против использования for in в массивах. / вообще очень сложно читается, лучше – Не смотря на то, что массивы это объекты, обычно не имеет особого смысла использовать для них цикл for in. Более того, существует ряд причин против применения for in в массивах
7. Единственный способ исключить ненужные свойства — использовать hasOwnProperty, а это в 20 раз медленнее обычного цикла for. / Вообще неверно переведено. Почему это использовать hasOwnProperty – медленнее? Нет, тут имелось ввиду вот что: / Поскольку for in перебирает все свойства в цепочке прототипов, а единственный способ исключить эти свойства – использование hasOwnProperty, то это до 20-и раз медленнее, нежели простой for.
8. Конечно, «синтаксис литеральной нотации» звучит круто, но нихрена не понятно. / объявляя новые массивы рекомендовано всегда использовать массивы-литералы при помощи конструкции [] / и вообще, «литералы» это хорошо, но ведь «константы» — понятнее.
9. заполненный случайными значениями / sparse array это попросту разреженный массив, т.е. такой, где для каждого элемента выделена память, фактически он будет заполнен не случайными значениями, а значениями undefined
10. таких как повторение строк / почему строк, если в оригинале «повторение строки»?
11. сравнения значений объектов на равенство / просто – «два способа сравнить значения объектов»
12. подразумевает приведение обеих переменных к одному типу для того, чтобы произвести сравнение. / в оригинале проще написано – «JavaScript использует слабую типизацию. Это значит, что оператор сравнения выполняет приведение типов для того чтобы сравнить значения»
13. поломан более чем полностью / практически непригоден для использования
14. В примере выше Object.prototype.toString вызывается со значением this, являющимся объектом, значение [[Class]] которого нужно получить. / Фактически toString вызывается таким образом, что значение this внутри нее будет позаимствовано у того объекта, чей класс мы хотим узнать. (это предложение мне показалось сложным для понимания)
15. они могут отличаться в различных реализациях / thus, they can differ across various implementations / могут различаться в зависимости от способа использования. (мне кажется речь идет не о вариантах реализации компилятора, а о вариантах использования typeof)
16. из-за слабости типизации JavaScript / из-за того, что в JavaScript используется слабая типизация
17. приведет к еще большему насилию над типами. / Type coercion is a somewhat ugly looking term which refers to a PostgreSQL method for changing a value from one data type to another. / In addition, having literals or non-object values in there will result in even more type coercion. = Кроме того, использование литералов или необъектных значений [в этих конструкторах] вызовет еще больше преобразований типов.
18. Нативности / Core / может быть просто «Ядро»?
19. 99.9% случаев её «использования» могут достигаться без её участия. / 99.9% of its «uses» can be achieved without it. / В 99.9% случаев тех же результатов можно достичь и без ее применения.
20. eval под прикрытием. …поскольку eval в этом случае вызывается не напрямую. / Неявный eval. …хотя eval и не вызывается напрямую. (since == seeing that)
21. Если вдруг для работы вам необходим eval, эта часть должна тут же ставиться под сомнение и не должна использоваться в первую очередь / Если что-то требует использования eval, следует поставить под сомнение такой способ реализации и не использовать его на первых порах.
22. Параметры, которые не были переданы в функцию явно. / т.е. в тех случаях, когда в функцию не был передан параметр, описанный в ее определении (тут предложение выбивается из текста, но не потому, что неверно переведено, а потому, что каждый элемент перечисления должен отвечать не на вопрос «что?», а на вопрос «когда?»
23. При доступе ко всему, чьим значением является undefined. / Если чему-то уже присвоено значение undefined
24. Парсер радикально подменил поведение / парсер кардинально изменил поведение (вообще слова «радикально» и «драматично» нужно использовать в русском языке с опаской – они не применяются у нас в тех случаях, где в английском языке их можно применять)
25. В то время, когда исполняющийся код будет блокироваться во время вызова с таймаутом, setInterval будет продолжать планировать последующие вызовы переданной функции. Это может (особенно в случае небольших интервалов) повлечь за собой выстраивание вызовов функций в очередь. / Пока выполняемый код блокирует следующий вызов по таймауту, setInterval продолжит генерировать вызовы указанной функции. Это может (особенно в случае небольших интервалов) привести к тому, что вызовы функции выстроятся один за другим, т.е. вовсе без временного интервала между вызовами.
26. Кроме того, избегайте использования setInterval в случаях, когда его планировщик может блокировать выполнение JavaScript. / Кроме того, избегайте использования setInterval, поскольку его планировщик не блокируется выполняемым кодом.