Russian Qt Forum

Как известно, существует проект перевода документации Qt на русский язык. Сразу скажу, что очень уважительно отношусь к труду таких людей. Тем более, что делается это все на чистой инициативе...
Вопрос к обсуждению следующий: а надо ли оно??

Чтобы меня тут сразу не растерзали на куски  :), поясную свою позицию.

1. Обновления библиотеки и документации выходят довольно часто. Например, сегодня команда переводила для версии 4.5.0, а завтра выходит версия 4.5.6. Значит для поддержки актуального состояния перевода, нужно отслеживать все изменения. Возникает большой риск что-то упустить. Следовательно дать читателю не полную информацию.
Да и вообще, переводная документация по-сравнению с оригиналом всегда неполна, ввиду постоянного обновления последнего.

2. Язык документаций (любых) всегда прост для понимания, и не требует глубокого знания языка. Это дает возможность практически всем заинтересованным людям нормально пользоваться ей. А программистам вообще желательно как можно раньше приучать себя к чтению документации на англ. языке, потому что на практике постоянно возникают ситуации, что на англ. документ есть, а на русском - никогда не было.

Так не лучше ли иметь единственный вариант на оригинальном языке, написанный авторами продукта и везде ссылаться именно на него? И не тратить кучу драгоценного времени на трансляцию текста, дополнительно порождая проблемы перевода?

Кто что думает по этому поводу? :)

Странная тема...

По поводу перевода: оригинальная документация не переписывается полностью от версии к версии, возможно меняются небольшие части по существующий классам и добавляется документация по новым. Т.е. переводить приходится в основном новые части и при необходимости модифицировать уже переведенные. Все это легко отслеживается.

По поводу а надо-ли... Люди занимаются тем, чем они хотят заниматься. Если для кого-то это не нужно, то это не значит что это не нужно никому...

Что должна прояснить эта тема?

Соглашусь с автором. Наивно полагать, что для новичков проблема понимания библиотеки упрётся в языковой барьер официальной документации. Думаю перевод на русский совершенно не нужен. Если человек не может прочитать документацию на английском исключительно из-за плохого знания последнего, то и документация на русском ему мало поможет. Таким новичкам и с примерами то разобраться сложно.

В первую очередь проблемы возникают из-за плохого знания C++.
Далее из-за того, что ленятся читать примеры, чужой исходный код, экспериментировать.
Далее проблемой стаёт плохое понимание архитектуры библиотеки, системы обьектов, событий, контейнеры, многопоточность и так далее.

Ни одну из этих задач документация на русском не решает.

- Для изучения C++ есть специализированая литература.
- Для экспериментов есть огромное количество примеров в директории самой Qt, для запуска которых вообще знать Qt не нужно.
- Для изучения архитектуры Qt есть книги по Qt на русском языке, где шаг за шагом с самых азов разжёвывается что да как. Эти книги документация на русском языке заменить не сможет, разве что перевод отдельных обзоров из Qt.

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

типичная ситуация, когда специалист дозревает до нужной степени некомпетентности - все приобретенные
им навыки воспринимаются им как нечто дающееся от природы с последующими выводами.
в этом состоянии индивидуум смотрит на источник обучения (переведенный мануал) как на ненужный фетишь.
спуститесь с небес господа и почитайте Карнеги, конкретно опо ораторскому искусству и конкретно главу
"Секрет резервных знаний".

не лучше. вы не вьехали в технологию перевода, она упрощенно инкрементарная, т.е. однажды переведенный уникальный фрагмент нет необходимости переводить во всех версиях документации, он переведется автоматом, а уже строете преположения на неверно поданных исходных данных. Двойная ошибка только в постановке вопроса.

Вообще-то после слов "Соглашусь с автором" я написал почему именно. И не заметил никаких опровержений с вашей стороны. Могу сказать за себя - ни разу при изучении Qt я не чувствовал, что мешает мне имеено английский язык. Более того, технический английский программист обязан знать в любом случае. Я придерживаюсь мнения, что разработчик не должен идти по пути наименьшего сопротивления. Конечно же идеальных решений не бывает, но к ним нужно стремиться, и если задача требует - нужно изучить предметную область, неважно будет ли это теория, API какой-нибудь библиотеки или английский язык.

Повторюсь, новичкам, плохо разбирающимся в C++, ни английская, ни русская документация не помогут. Им гораздо важней толковая книжка или набор статей. А ещё лучше - ходить на уроки и не бежать впереди паровоза. Не могу представить школьника, которому важней кое-как программировать, чем знать английский. И не могу представить студента, который английский не знает, учить не собирается, но уже хочет программировать.

Идя на поводу у собственного "хочу" мы воспитываем в себе быдлокодера.

Действительно, начиная программировать я, как и очень многие другие, в первую очередь искал руководство на русском. При этом во главу угла мной ставилось не качество перевода, не его актуальность (по естественным причинам он всегда запаздывает), а только то, что документ написан на родном мне языке. Куча времени тратилась только на поиск переводов и статей, не важно каких, но на русском. Что мне это дало? Сейчас я думаю, что это только затормозило мое развитие. Лучше потратить это время на изучение языка, потому что рано или позно, но каждый, кто серьезно интересуется IT, приходит к этому. А наличие альтернативного русского варианта по сути не дает ничего, кроме иллюзии, что изучать язык оригинала нет никакой необходимости (а зачем, если команда переводчиков нам все разжует?). В итоге "пиплы, которые не хавают инглиш", и не собираются в него вникать, либо проходят годы, прежде чем они приходят к такой необходимости, оглядываются назад и понимают, сколько времени они могли бы съэкономить, если бы сразу уделили этому достаточно внимания.
Не так уж и редко встречается ситуация, когда выбор между тем, какую технологию использовать, решается наличием/отсутствием документации на русском, а не тем, насколько данная технология подходит для конкретной задачи.

Возможно. Лично для себя я решил по-возможности избегать русских переводов. В первую очередь, для того, чтобы приучать себя пользоваться всей доступной информацией и из оригинальных источников. Как показывает практика такой подход позволяет набрать нужный уровень языковой подготовки за очень короткое время, гораздо меньшее, чем может показаться в начале, а не заниматься укреплением собственных языковых барьеров. Это как с десятипальцевым методом печати на клавиатуре - сначала все получается медленнее чем двумя пальцами, но стоит немного потренироваться и все с лихвой окупается!

Мне стало интересно, чем люди мотивируют (кроме, получения самоудовлетворения конечно) свой колоссальный труд... Если они думают, что это помогает кому-то в профессиональном росте, то смею утверждать, что это заблуждение.

to Dendy: согласен на 100%.  :)

P.S. Еще раз подчеркну, что речь идет о необходимости перевода именно документации, представляющей краткую справку по используемому инструменту. Переводить классиков можно, и нужно обязательно!

Как у всех фрилансеров, думаю мотивация здесь ясна - чувство востребованости результатов труда. Тем более труд можно пощупать и оценить. Но думаю стоит таки иногда отойти на шаг назад и постараться обьективно посмотреть на цель своей деятельности. Обьём проделаной работы виден? Да. Её оценивают? Да. Есть ли толк? Сомнения...

Любой лодырь с большим удовольствием будет жевать конфеты, в то время как его стоит загнать за школьную парту, и если нужно - розгами. Это он потом спасибо скажет, через года. На этапе воспитания нужно пресекать порочные соблазны и поощрять полезные. К сожалению "программист" - это одна большая хохма как раз из-за подавляющего большинства таких вот самоучек, которые галопом по европам за неделю "осваивают" язык. А потом о них рассказывают анекдоты.

Чтобы программировать нужна большая теоретическая база: математика, пространственное мышление, знание работы компилятора, понимать что такое стек, указатель. Начав программировать не с того конца есть риск похоронить теоретические знания, которые ой как тяжело будет изучить в будущем, ведь хочется всего и сразу. Если кто-то ловит себя на мысли "Хочу написать вот такую красивую программу", но при этом даже не представляет с какого конца подобраться - спросите себя, действительно ли оно вам надо? А сколько людей вместо понимания основ 3D графики сходу пытаются программировать на OpenGL?

Лично я сильно сомневаюсь, что стоит начинать знакомство с миром программирования с Qt, то-есть именно тем людям, для которых английский язык - проблема. Qt - сложная библиотека, воплощающая сильные стороны C++. Новичкам гораздо полезнее начинать с С, который на порядок проще, ближе к компилятору и пониманию принципов работы программы.

Я действительно ценю энтузиазм переводчиков и их стремление сделать доброе дело. Но пропустив потенциальных читателей через все фильтры мне так и не ясна целевая аудитория, на которую рассчитан перевод.

хм, я бы не сказал, что она "краткая" :)

Краткая в том смысле, что описание каждой сущности ограничивается ее словесным определением, перечислением свойств и методов, указанием зачем нужен тот или иной метод (1-2 предложения). Так как и должно быть в нормальной документации. Внушительный суммарный объем получает из-за большого количества классов. А вообще меня очень порадовала документация к Qt - лучшее из такого рода продуктов, что я встречал. :)

почему-то, многие упускают из виду крайне важную деталь - скорость поиска ответа на свой вопрос в документации.
Представим себе текст на чужом языке и человека знающего его не в совершенстве. Такой текст невозможно прочитать "по диагонали", т.к. глаз за фразы не цепляется - для меня это абсолютная аксиома.
Использование полнотекстового поиска (не предметного указателя), также вносит затруднения, если речь не идёт о поиске названия класса/метода.

П.С. "нужно ли?",
Х.З., но статистика загрузки переводов с кросплатформы - 1,5...3 тыс. в мес.

Если не секрет 1.5...3 тыс. - это чего и в каких единицах.

Я думаю, многие из нас хотели бы популяризации Qt.
Насколько ни была хороша эта библиотека, её используют отсносительно небольшое количество людей (по сравнению с другими фреймворками - .Net, VCL, и т.д.). Она редко встречается в университетских курсах, в отличии от того же VCL.
Создание такого замечательного IDE как QtCreator, перевод его интерфейса и справки, перевод документации Qt - те меры, позволяющие снизить порог вхождения в Qt. Qt становится ближе к людям!

Кстати, MSDN тоже частично переведен на русский язык, однако ни у кого не возникает вопроса "Зачем?".

>>Если не секрет 1.5...3 тыс. - это чего и в каких единицах.
раз в месяц

Что раз в месяц вы уже сказали. А чего скачивается-то раз в месяц?

Вопрос в том - стоит ли оно того. Не нужно забывать, что Qt - всего лишь инструмент. Знание библиотеки никак не заменит толстого слоя теории, необходимого каждому программисту. Как и любой другой, любящий свой инструмент - я за популяризацию Qt. Но снижение порога вхождения... я бы сказал - не наш метод.

Это как снижение порога вхождения для бензопилы - с 10 лет. А потом вызывать коронёров в каждую школу.

Не такая уж она и хорошая, проблем валом.
Да, стабильна ричева и продумана. Но если пишешь че-то серьезное, то лучше WTL/GTK в зависимости от платформы.

Пожалуйста, дальше без офтопа. Тем более такого голословного. [Dendy]

Вы сравниваете фреймворк с библиотеками построения гуи. Это неправильно.
Но даже если рассматривать этот аспект,  то я с трудом себе представляю, как можно используя WTL создавать приложения со сложным, динамическим GUI. Одни карты сообщений чего стоят. А где там Layout-ы? Поседеешь, пока напишешь на WTL что-то серьезное.

Дальше будет резаться. Сравнивать тулкиты - наздоровье. Только в соседней ветке. [Dendy]

в соседней так в соседней, велком >>>: тута (http://www.prog.org.ru/topic_11868_0.html)
Пс. Смайлы поменяйте плз. мутные какие-то....

>>А чего скачивается-то раз в месяц?
документация (та что по ссылке "скачать", здесь (http://www.doc.crossplatform.ru/qt/)).

Спасибо за ссылку, скачаю - почитаю. А как вы видите количество скачиваний в месяц?

>>А как вы видите количество скачиваний в месяц?
админ ставил счётчик. сейчас он вроде не пашит, после очередного переезда части кросплатформы на другой сервер.

в случае с/с++ да.

разве? ;)
обьясните реализацию рекурсии в жава машине.

Любой профессионал должен знать свой инструмент на один уронь глубже, чем он использует в повседневной практике. Не представляю себе программиста (на любом языке), который не знает про аллокацию памяти, указатели, стек. Даже если он их напрямую никогда не использует.

Речь шла вообще-то о:
Так что во-первых, речи о профессиональном программировании тут не было, а во-вторых, не хочу разочаровывать, но без них действительно можно профессионально программировать! ;) На java (исключение - стеки, если речь действительно о профессионализме, т.к. и без них можно легко обходиться), VB, PROLOG(как ни странно ;D), PHP и т.д. и т.п., так что это уже пошли отмазки разные и показ "у кого длинее". Просто С-прогеры в очередной раз хотят показать что их язык "пуп вселенной" :) Я понимаю конечно, что без указателей в С++ никуда (даже знаю как они работают - из универских лекций по С++), в ассемблере и паскале/делфи они тоже есть, но не надо их приписывать к программированию в целом.

А вы меня и не разочаровали, поскольку аргументов я у вас не увидел. Речь то не о том, можно ли или нельзя написать. Можно то можно, и оно возможно даже будет работать. Но не стоит забывать, что программирование состоит из множества факторов: правильный выбор языка, читабельность кода, скорость написания, скорость выполнения, количество ошибок, возможности расширения и так далее. И профессионализм определяется насколько программист сможет "схватить" задачу и выбрать оптимальный вариант её решения. Так вот, без знания как устроен инструмент шаг влево-вправо от задачи - и "программист" начинает плавать. Неправильно выбрал контейнер или алгоритм - сожрал лишню память и затормозил программу. Не стал разбираться в многопоточности, когда это требовала задача - получил тормозной код, вешающий интерфейс. Применил потоки, но не понял как они работают - получил race condition или dead lock. И здесь никакая жава не спасёт, если разработчик не знает основ.

Какое ЭТО всё имеет отношение конкретно к стекам и указателям для программирования в целом?

А тут вообще не понял. Что значит "никакая жава не спасёт"? Ну а если я знаю основы этой жавы, тоже не спасёт? Или может меня спасёт в этом случае знание сишных указателей?))

Вобщем, наверно, я цепляюсь к словам (когда завёл речь конкретно о стеках и указателях).

Никто и не говорил о программировании в целом. Существуют ведь книги "Изучить ${PROGRAMING_LANGUIAGE} за 3 дня", прочитав которые можно что-то написать. Значит тезис в целом оспаривать нельзя, и такая литература тому подтверждение. Другое дело насколько такой программист будет квалифицирован.

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

Я старался не отрываться от темы, прошу прощения, если похоже на оффтоп (-: Идея в том, что начинать программирование с высокого уровня довольно сомнительно. К примеру, изучать Java, но не знать о работе памяти. Или изучать Qt когда матчасть по C++ хромает. Считаю, что документация по Qt на русском провоцирует человека начитать изучение не с того конца.

я сам не программист по профессии, писал проги на дельфи, визуал басике и билдере.
Могу сказать, что Qt заставляет вникать в Си++. А это уже +. (каламбур получился :) )
Единственные провокаторы - Дизайнер и Креатор.

А дока на русском, ничуть. Это вообще никак не влияет на то, будет ли человек разбиратся с Си++ или нет. Т.к. при переводе доки не вносится ни каких изменений в этом плане.

Насчёт документации я там выше задавался вопросом, но меня так никто и не просветил. Какая целевая аудитория этого перевода? Технический английский достаточно прост, документацию на русском можно заменить переводчиком и школьными знаниями языка. А те, кто переводчиком не пользуются, английский в школе не учили и хотят программировать им нужна бумажная книжка по Qt и C++. Пропустив через все фильтры я могу выделить разве что тех, кому горит на завтра сделать лабу по программированию, язык они не знают, учить им его некогда/лень.

О целевой аудитории можно гадать долго.
Мой ответ на твой вопрос есть здесь (http://www.prog.org.ru/index.php?topic=11857.msg74011#msg74011).
Я сам предпочитаю читать перевод, нежели оригинал.

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

Опять фразы, выдраные из контекста.


Под переводчиком я больше подразумевал словать терминов.

>>Под переводчиком я больше подразумевал словать терминов.
это слишком долго для поиска нужных мест в документации. (см. замечание о чтении "по диагонали")

никому этого не говорите ;)

уточню вопрос: что произойдет со стеком и всеми объектами в нем, если при рекурсии, функция/метод, в N-ом вложении бросит исключение?
не знаете? - тогда не говорите о профессиональном программировании.

а вообще, Dendy по большему счету, правильные аргументы привел. знание принципов/теории/алгоритмов необходимо по любому, не зависимо от используемого ЯП.

не правда. использование указателей, как-раз говорит о не профессиональности. читаем про http://ru.wikipedia.org/wiki/RAII (http://ru.wikipedia.org/wiki/RAII). это не относиться к какому-то конкретному ЯП. При использовании техники RAII и ссылок, надобность в указателях отпадает.

а по поводу:
так и есть. потому что ни на одном другом ЯП невозможно написать ОС. а нет ОС - нет интерпретаторов, нет ВМ ;) а значит нет явы, php, и т.д. и т.п... :)
на С/С++ можно реализовать АБСОЛЮТНО все! чего не скажешь про все остальные ЯП ;)
тем более не стОит говорить про производительность программ, очевидно.
и т.д. и т.п....

модераторы, простите за флуд ;)

Я в яве не использую указатели. Это непрофессионально?)

не знать все плюсы и минусы используемого ЯП - это не профессионально. а стек и алгоритмы знать надо.

остальное холивар.

>>использование указателей, как-раз говорит о не профессиональности.
:D

Юра, читаем RAII, и изучаем это:
http://www.boost.org/doc/libs/1_41_0/libs/smart_ptr/smart_ptr.htm (http://www.boost.org/doc/libs/1_41_0/libs/smart_ptr/smart_ptr.htm)
и это:
http://www.boost.org/doc/libs/1_41_0/libs/utility/utility.htm (http://www.boost.org/doc/libs/1_41_0/libs/utility/utility.htm)

и убеждаемся в том, что применять указатели не за чем ;) при том, использование RAII, избавляет от "ручного" управления ресурсами(память, файлы/сокеты, и всего что нужно "выделять")
при том, то что по вышеприведенным ссылкам, уже вошло в стандарт :P

Это наверно отдельный вопрос, т.к. если ЯП сам чистит память, то за это наверняка надо расплачиваться скоростью работы приложения. А можно ли называть непроффессионалом того, кто заботиться о скорости?

но не в случае с С++.

niXman, в Qt только  и делаешь, что используешь указатели.
В Википедии про RAII (Получение ресурса есть инициализация) написано:
А разделяемые объекты, не единственные в программе.

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

пример пожалуйста, который не может быть реализован с использованием RAII.

Для обсуждения RAII создавайте отдельную тему. Дальше только по существу. [Dendy]

Скачал таки переведённую документацию Qt, решил посмотреть своими глазами. Начиная с главной страницы и наобум тыкая по классам я не нашёл ни одного файла переведённого от начала до конца. Абсолютное большинство даже не касалось перо переводчика. Повсюду режущие глаз мелочи, литературный перевод хромает, видно что слова переводились буквально, иногда не заботясь о смысле целых фраз. Заметно, что переводчиков несколько и некоторые откровенно игнорируют букву "Ё", в результате чего мне, как человеку знающему алфавит, читается с трудом. Про запятые уже молчу.

Возможно это моё субьективное мнение, но в целом документация нечитабельна. Дело в том что в оригинале исходный код на пару с английскими комментариями читается как книга. Ни у кого не возникает вопросов что делает метод QWidget::insertAction() или QImage::convertToFormat() - они самодокументированы. В русском же варианте это мешанина разноязычных слов смотрится жутко. Конструкцию доксигена \a argument переводчики в некоторых местах заменяют на скобки, this заменяют на этот, этого, этим, true и false иногда переводятся как истина и ложь. Например:

Некоторые фразы я не осилил:

Решил заглянуть в основу гуя всего - класс QWidget. Переведённым оказался лишь первый абзац.

Решил копнуть ещё глубже - ну про QObject ведь точно должны рассказать, без него далеко не уедешь. Увиденное заставило остановиться и прокомментировать подробнее.


> Автосединение
Как бы намекает что будет с вашими волосами после прочтения следующих строк.

> До тех пор, пока объекты определены с надлежащими именами, а слоты соответствуют простому соглашению об именовании...
Как новичёк не знающий Qt я бы ничего не понял.

> может быть выполнено во время выполнения
Масло масляное.

> uic генерирует код, который вызывает эту функцию, позволить выполнятся автосоединению между виджетами на форме, созданной с помощью Qt Designer.
Паавтарите пожалуйста, я ззаписываю... И на десерт завершение абзаца английской фразой. Сами методы QObject не переведены вообще.

Некоторые фразы имеют ложный смысл:

В оригинале под этим массивом подразумевается this, в русском же варианте читается как будто возвращается ссылка на ba.

Здесь явно что-то пропущено:

Точность плавающей запятой - это сильно.

Без комментариев.

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

Собственно, в текущем виде я слабо представляю как человек без знаний английского и C++ сможет в этом разобраться. Гораздо полезнее посвятить недельку-другую изучению технического английского, чем ломать глаза об симбиоз латиницы с великим и могучим.

P.S. "Статический открытый член" доставляет.

Я бы добавил, что знание классического С++ и английского недостаточно для понимания данного текста, если дополнительно под рукой не будет оригинала. Неудивительно, что потом на форуме появляется куча вопросов, ответ на которые можно элементарно найти в документации: заглянул человек в русский вариант, почитал и понял, что спросить проще будет, чем продирать сквозь трудности перевода. Что в свою очередь постепенно отучает начинающих программистов от самостоятельных исследований.
Проблема переводных документаций гораздо глубже чем может показаться сначала. С другой стороны связь между знанием программистом тех. английского языка и его профессиональным уровнем очевидна. Я поднял эту тему, чтобы побольше людей выбирали правильный путь, а не тот, который кажется наиболее простым на данный момент. Потому что в конечном счете при освоении английского варианта отдача будет намного больше.

P.S. Отдельное спасибо Dendy, раскрывшему многие ключевые аспекты. :)

Ну, кинуть какашкой всегда проще, чем сделать что-то полезное. Я вижу и ценю труд людей, вложивших силы в перевод, главное - что они хотели сделать что-то хорошее для общества.

Выше по треду, говоря что проблем с чтением документации на английском у меня не было, я конечно же слукавил. Начинал я в далёком 2003-м, когда не то что русскоязычного сообщества Qt не было - интернет выдавали по карточкам (Пастор не даст соврать). И я благодарю случай, что тогда у меня не было русской документации. И за знаниями вгрызался я в тот самый ассистант, держа под рукой словарик, заучивая незнакомые термины. Лучше день бежать, зато потом за пять минут долететь.

Дааа, было дело ))))

По сабжу: Лично я необходимоти перевода документации невижу. Документащия Qt написана на даваольно понятном и простом техническом английском. Трудностей с переводом практически некогда небыло.

после краткого анализа Dendy к такому переводу никогда обращаться не буду.

Пара недель явно мало. Да и нормальных обучалок маловато. Может ччего подскажешь на эту тему?

Камрады! Мне с самого начала не была понятна цель данного обсуждения, так она и не прояснилась до сих пор.
Есть группа людей, которая занимается переводом документации не требуя ничего взамен, тратят свои силы и время. Они не навязывают использовать эту документацию вместо авторской. Если кому то это не нужно, то можно не пользоваться.
Не нужно никому навязывать что ему делать и как. Хотят этим заниматься - это их право, за это им можно сказать только спасибо.
Целесообразность в огромном количестве текстовых редакторов, которые сейчас есть в мире, тоже вызывает вопрос. Но если хоть один из тысячи новых редакторов добавит одну удобную функцию (которую через год будут иметь другие редакторы) - это уже прогресс.

А почему вспомнили недавний 2003 год? Давайте вспомним 1988. Тогда не было не то, что русскоязычного сообщества Qt, тогда еще и интернета не было, и даже FIDO не было. Книг не было, документации не было, исходников не было... Сейчас все это есть в избытке, все этим с удовольствием пользуются и никто уже не готов от этого отказаться.
Так почему же нужно останавливать этот прогресс? Возможно через год-два документация на русском не будет отличаться от английской по качеству. Если сейчас есть недочеты, то IMHO лучше помочь с переводом или как минимум указать на эти недочеты.

Dendy, жёстко. Только для чего?
Перевод пока не закончен. Он развивается. Главное его достоинство - это переводы HOWTO
Базовые контейнеры (http://doc.crossplatform.ru/qt/4.5.0/containers.html)
Каркас графического отображения (http://doc.crossplatform.ru/qt/4.5.0/graphicsview.html)
Программирование Модель/Представление (http://doc.crossplatform.ru/qt/4.5.0/model-view-programming.html)
и т.д.

Надеюсь, что перевод будет и дальше развиваться.

мдя, Dendy похоже недоспал.

Я соглашусь, что изначально не очень четко сформулировал тему. Речь идет о выработке правильного подхода в освоении материала. Критерий - наибольшая эффективность в расчете на затраченное время.
Никто никому  ничего не навязывает - здесь только делятся собственными аргументированными мнениями по теме. Тем более, что никаких средств навязывания не существует.

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

Я тоже за прогресс. IMHO, прогресс в любой области человеческой деятельности определяется количеством высококлассных специалистов.

* А почему бы не отказаться от документации вообще (авторской в том числе), ведь человек который будет осваивать Qt по исходным кодам самой библиотеки узнает ее глубже.
* А почему бы не закрыть исходники Qt, пусть человек изучает ее дизассемблируя код. Ему это пойдет только на пользу.
* А почему бы не прекратить обучать программированию в вузах, ведь человек для которого это важно/интересно и так этому научиться, а уровень его подготовки будет выше.

Мне кажется русскоязычная документация на Qt не самое большое зло в становлении специалиста.  ;)

;D
кстати, в последнем пункте есть рациональное зерно: в некоторых ВУЗах так преподают программирование, что лучше запретить от греха подальше..  :D

Всем огромное спасибо, за то, что добрались до самой документации, Dendy в первую очередь.

Dendy по твоему сообщению:
1) До прошлого года переводилась в ручную версия 4.4.х, остальные версии переводятся автоматом из памяти переводов (далее ПП). Поэтому в других версиях могут быть файлы в которых переведены отдельные строки.
Переводчик переводит файл целиком, переводит только то, что ему интересно (иначе стимула переводить нет). По этому не переведён QWidjet. QObject, после завершения перевода "Подробного описания" был отложен в сторону, для перехода на перевод версии 4.6.х.

2) Переводчиков действительно несколько. Ещё есть перевод который нам задарил один человек. Этот перевод оставлен как есть, и исправлений в него вносилось минимум, только когда кто-то сообщал об ошибках.

3) насчёт описания функций-членов класса, если есть предложения, то предлагайте (на этом месте обычно все куда-то испаряются). Но правило должно быть чётким и понятным. Как обращаться к аргументам. Как использовать this (который в тексте, к стати, ни как не выделен).

Основная проблема - почти полное отсутствие замечаний со стороны пользователей. Я их (пишущих замечания) знаю поимённо, одной пятерни хватит, чтобы посчитать.

- к аргументам обращаться используя идентификаторы из сигнатуры метода (как сейчас и делается);
- если под this понимается указатель на собственный экземпляр (должно быть понятно из контекста), то он не переводится.

Пока проблема с правилами перевода методов не совсем ясна. Если можно, то хотелось бы пример, где возникает неоднозначность, чтобы сделать обсуждение более предметным...

пример:
здесь this ни как не выделен. Потому-что по английски он  что так "этот", что эдак.

переведено так:

В данном случае this представляет собой указательное местоимение, поэтому и не выделен никак.
Согласен, что в самой фразе есть неоднозначность, но если не выдирать ее из контекста, то из QByteArray & QByteArray::insert ( int i, const QByteArray & ba ) можно понять, на что возвращается ссылка.
Исходя из этого, я бы заменил дословный перевод местоимения, чтобы более конкретизировать обозначаемую им сущность. Например, так:

Вставляет байтовый массив ba на позицию с индексом i и возвращает ссылку на результирующий байтовый массив.

>>результирующий
в этом-то и загвоздка, новый массив не создаётся, этотже (этого экземпляра класса) массив используется.

Был бы очень благодарен еслиб помогли подобрать универсальный вариант. Дело в том, что контекст (класс) всегда разный а предложение почти всегда одинаковое во всех классах.

может просто всегда писать так:
... этот (this) ...

а почему слово "результирующий" должно ассоциироваться с созданием нового массива? Результатом применения метода является исходный массив, в который добавили добавили новые элементы. Результат операции это не всегда новый объект.
Если не нравится слово "результирующий" можно поменять его на "модифицированный", например.


Перевод с естественных языков процесс творческий, никаких универсальных вариантов для "всех случаев" не существует. Зависимость от контекста является одной из самых нетривиальных проблем при переводе, его творческая составляющая. Остальное - дело техники.

если оставлять слово "этот", то по правилам русского языка оно будет относится к массиву ba, что полностью изменяет смысл фразы. При этом слово (this) в скобках смотрится очень странно, только запутывает - имейте в виду, что возвращается не указатель this, а ссылка на объект.

Чтобы сделать универсальный вариант нужно просто ничего не делать (-;