Yii Framework

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

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

Кстати, я так и не понял, нафига в гуглекоде было переводить файлы(!), когда я считаю нужно API перевести (для чего нужно и как юзать).

Sam Dark писал(а):API постоянно меняется, поэтому перевод постоянно устаревает. Чтобы это отслеживать и работать над переводом командой нужен как минимум SVN. То, что сейчас в http://code.google.com/p/yiiru/ уже не актуально, хотя Алексей вложил в перевод довольно много сил и времени.

Да, работа над переводом приостановилась, но она есть. Как минимум то, что уже есть в гуглекоде, поддерживается в актуальном состоянии (правда, локально пока). В данный момент доделываю обновленную диаграмму классов.

Одиночка Айс писал(а):Кстати, я так и не понял, нафига в гуглекоде было переводить файлы(!), когда я считаю нужно API перевести (для чего нужно и как юзать).

Какую версию АПИ Вы предлагаете переводить? И есть ли какие-то вообще идеи по переводу АПИ, но с заделом на будущее, на возможность обновления и синхронизации с оригиналом?
Перевод файлов как минимум проще - я могу заглянуть в код метода, чтобы убедиться, что правильно понял фразу. Плюс, легко можно использовать (будет когда-то, надеюсь ))) переведенный пакет при разработке.
А вот синхронизация тяжеловата конечно. Придумать бы что-то достаточно удобное...

Для начала, не помешало бы перевести нечто общее, вряд ли метод app() или getVersion() будут меняться, дальше думаю по запросам пользователей, хотя... хз, решать разработчикам и переводчикам.

Есть одна идея, судя по phpdoc комментам там для каждого метода указано с какой версии фрэймвока он не менялся(если я верно понял), так вот на основе этого можно написать скрипт/прогу которая бы извлекала из php файлов phpdoc комментарии, проверяла их изменились они или нет(изменился ли функционал метода), и если да, то подставляет описание на английском, иначе на русском.

Уважаемое сообщество, извините, но я считаю переводить API - это просто бредовая затея. Во-первых, как бы вы не старались - перевод всегда (или почти всегда) будет не актуальным, во-вторых, он очень зависит от переводчика (то есть, не всегда сохраняет первоначальный смысл), в-третьих - ну зачем? Я не думаю что для кого то есть проблемно прочитать небольшое описание или пояснение на английском, если это не так - то это реально проблема такого человека и ему стоит о ней задуматься. Не хочу никого обидеть - но это факт.
Лучше все эти силы (которые будут затрачиваться на переводы API) направить в действительно нужное русло - примеры, примеры и ещё раз примеры.
Вот это проблема документации, а не перевод. Да перевод мануала, возможно кому то пригодиться, возможно даже многим (так как там текста много и часто он очень отходит от технического), но не стоит заниматься переводом API, лучше напишите примеры.

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

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

Одиночка Айс писал(а):Для начала, не помешало бы перевести нечто общее, вряд ли метод app() или getVersion() будут меняться, дальше думаю по запросам пользователей, хотя... хз, решать разработчикам и переводчикам.

Посмотри их английские описания. Зачем их переводить? Проблемно понять для чего они (если не с названия, то с английского описания)? Зачем делать ОГРОМНУЮ и глупую работу?

Солидарен с snowflake. Лучше писать мануалы и как-то удобно структурировать их, чтобы можно было легко найти нужный мануал по различным критериям. Перевести 3 строчки описания API можно и в ГуглТранслейте, если у кого-то уж совсем всё плохо с английским.

Может сделать какое-то YiiWiki? Правда там поиск не удобный...

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

Одиночка Айс писал(а):Но прежде чем писать мануалы, нужно ПОНИМАТЬ как это все работает. Короче, пока мы тут воду льем, время идет, и каждый мучается сам по себе, лишь изредка спрашивая совета у других.

Абсолютно согласен, но мне для понимания очень не хватает примеров в API, именно примеров, так как их нет, из-за недопоняток приходится или искать примеры или смотреть в корень (к код фреймворка). Хочу подчеркнуть ещё раз не хватает примеров, а не перевода API.

snowflake писал(а):

Одиночка Айс писал(а):Но прежде чем писать мануалы, нужно ПОНИМАТЬ как это все работает. Короче, пока мы тут воду льем, время идет, и каждый мучается сам по себе, лишь изредка спрашивая совета у других.

Абсолютно согласен, но мне для понимания очень не хватает примеров в API, именно примеров, так как их нет, из-за недопоняток приходится или искать примеры или смотреть в корень (к код фреймворка). Хочу подчеркнуть ещё раз не хватает примеров, а не перевода API.

Аналогично, вместо 3х абзацев хоть на русском, хоть кухарском, пример является более наглядным и понятным для восприятия!

А вот теперь следующий вопрос: у каждого свои потребности, кому-то нужно одно, кому-то другое от одного и того же функционала. Тут как быть? От простого к сложному? Но опять таки, у одних может работать на 100%, а других с глюками, у третьих - вообще не будет работать.

Одиночка Айс
А поконкретней можно? Ничего не понял…

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

Ну, вишлист уже есть — это багтрекер Yii.

Одиночка Айс писал(а):А вот теперь следующий вопрос: у каждого свои потребности, кому-то нужно одно, кому-то другое от одного и того же функционала. Тут как быть? От простого к сложному? Но опять таки, у одних может работать на 100%, а других с глюками, у третьих - вообще не будет работать.

Это понятно что у каждого свои потребности, речь идет о том что большинству реально не хватает примеров в документации, под примерами я понимаю просто кусочки кода такого вида - если припустим у нас вот такая ситуация, то данный класс можно применить вот так вот. И чем более пример будет показывать преимущества Yii тем лучше. Пример служит отрывной точкой и наглядным пособием типа вот так вот должно работать. Пример может быть довольно абстрактным, но он должен показывать так сказать механизм использования и не более. А вот если тебе нужно что то по сложней сделать - тогда нужно это делать, но механизм как оно будет работать ты видишь.
А сейчас ситуация такая что на много простых вещей приходится тратить очень много времени, просто потому что ты не видишь как их предполагалось использовать. Вот и все. Думаю я правильно понял твой замысловатый вопрос и постарался донести мое мнение по поводу ответа.

Поддерживаю — примеры в API необходимы. Странно что это вообще обсуждается, примеры в API — это стандартная практика.

Да что примеры необходимы и так понятно. С обсуждением необходимости пора заканчивать и переходить к конкретным действиям — сбору заявок на примеры к классам и методам. Далее всё это дело я оформлю в тикеты и постепенно добавлю в фреймворк.