Re: mounik.org: пляцоўка-"пар асон" для беларускіх пр аектаў у IT

Дадатак:
Хосціцца ўсё-такі лепш на sourceforge.net (набор софта там нармальны +
стабільная пляцоўка з mediawiki, wordpress, bugzilla, trac ды інш.
майном, якое нам можа калі-небудзь прыдацца). Сёння дашлю туды запыт
на новы праект.

2010/10/22 Ihar Hrachyshka <[email protected]>:
> Прывітанне.
> Мы з Алесем паспрабавалі сфармуляваць тое, што ўжо выказвалася. Можаце
> яшчэ дзень-два памеркаваць, а на выходных пачнем інсталяцыю ўсяго
> майна на сервер і арганізацыю старонак. З тэхнічнымі пытаннямі мы самі
> разбярэмся, а вось калі ёсць ахвотныя дапамагчы з задачамі пункту
> "Арганізацыйныя задачы" (унізе), запрашаем да ўдзелу. Праз тыдзень-два
> рэсурс павінен збольшага функцыянаваць.
>
> ===
>
> Мэты:
> 1. стварыць пляцоўку для рэалізацыі творчага патэнцыялу груп, якія
> працуюць на ніве беларушчыны ў IT.
> 2. стварыць атмасферу для пачатку ўдзелу людзей, не абазнаных у тэхналогіі.
> 3. стварыць пляцоўку для акумулявання ідэй, практык, досведу, звестак,
> праектаў, вынікаў працы і для структуравання пералічанага.
>
> Тэхнічныя патрабаванні:
> 1. уніфікаваны пункт уваходу (ідэальна - адзіны лагін, магчыма - адзін домен);
> 2. наяўнасць простай сістэмы вэб-лакалізацыі;
> 3. наяўнасць пляцоўкі для зручнага акумулявання інфармацыі, даступнай
> для рэдагавання ўдзельнікамі;
> 4. наяўнасць форумных/рассыльных сродкаў камунікацыі з адзіным інтэрфэйсам;
> 5. уніфікаваны і зручны спосаб захавання праектных файлаў;
> 6. магчымасьць карыстацца напрацоўкамі суседніх праектаў(TMX), слоўнікамі.
>
> Домен: mounik.org (не kamputerm.org, бо рэсурс прызначаны не толькі
> для лакалізацыйных і тэрміналагічных праектаў).
> Хостынг/платформа: два падставовыя элементы - Wikimedia і Pootle;
> пляцоўка ўжо зарэгістраваная, ад AmbitiousLemon.
>
> Патрэбныя модулі:
> 1. Wikimedia: дакументацыя, ідэі, практыкі, старонкі праектаў,
> галоўная старонка.
> 2. Pootle: сістэма вэб-лакалізацыі.
> 3. Google groups: галоўны сродак аператыўнай камунікацыі.
> 4. GitHub ці інш. публічнае сховішча з сістэмай кіравання версіямі.
>
> Wikimedia:
> 1. усё інфармацыйнае і дакументацыйнае змесціва захоўваецца на вікі.
> 2. рэгістрацыя даступная для ўсіх.
>
> Pootle:
> 1. Рэгістрацыя даступная для ўсіх на ўзроўні ўнясення прапановаў.
> 2. Большыя правы выдаюць кіраўнікі адпаведных падпраектаў.
> 3. Трэба інтэграваць тэрміналогію і сінхранізацыю з upstream git.
> 4. Для аўтаматычнага стварэньня TMX раз на дзень мы потым зробім
> робата. Інтэграцыя з TMX: праграма updatetm абнаўляе спіс прапановаў
> для Pootle.
>
> Google groups:
> 1. Трэба вызначыць адзіны прэфікс для ўсіх падпраектаў: i18n-bel для
> лакалізацыі, mounik для астатніх?
> 2. Зарэгістраваць [email protected], які пакінуць для галоўнага
> месца рэлізаў, рэкламы і анонсаў усіх праектаў.
>
> Github:
> 1. Падумаць, ці можна сабе дазволіць Git, які цяжэйшы для засваення,
> чым класічны svn. Магчыма, трэба напісаць невялікі HOWTO, разьлічаны
> асобна на 1) проста перакладчыкаў, 2) тых хто будзе кіраваць. У
> прынцыпе, такі HOWTO ёсць у GNOME:
> http://live.gnome.org/TranslationProject/GitHowTo. Магчыма, варта
> найперш перакласці наяўныя матэрыялы, не трэба вынаходзіць кола.
> 2. У прынцыпе, ёсць іншыя варыянты. Кажуць, bzr і mercurial
> прасцейшыя, але здаецца няма публічных рэсурсаў, якія даюць магчымасць
> хутка рэгістраваць новыя сховішчы.
> 3. Ці ёсць сэнс для ўсіх праектаў захоўваць усе перакладныя файлы ў
> сябе ў лакальным сховішчы, калі яны: а) даступныя з upstream, б)
> аўтаматычна выцягваюцца і абнаўляюцца з upstream сістэмай
> вэб-перакладу, якая дазваляе сцягнуць канкрэтны файл або архіў
> праекта? З аднаго боку github павінен быць толькі прапануемым
> сховішчам, а праект сам можа вызначаць месца і сыстэму. З іншага боку
> - трэба настойліва раіць гэта рабіць.
> 4. Але калі будзе ўбудаваная інтэграцыя з upstream, то няма сэнсу
> сваёй сістэмы кіравання версіямі.
>
> Тэхнічныя задачы:
> 1. Трэба даследаваць магчымасць звязання прынамсі Wiki (Wikimedia) і
> Pootle (Django) з дапамогай адзінай сістэмы ўваходу. Тэарэтычна: ёсць
> OpenID-плагін для Wikimedia, а таксама Pootle карыстаецца стандартнай
> сістэмай аўтэнтыфікацыі Django, да якой можна прычапіць OpenID app.
> 2. Рэалізаваць бота-спамера, які перыядычна рассылае навіны праектаў у
> пэўныя месцы (ЖЖ, i18n@). Хаця гэта не першая задача, можна проста
> трымаць недзе невялічкі спіс з тых 5 месцаў. Нашы навіны раз на 2
> тыдні можна і рукамі даслаць. Будзе залежыць ад колькасці месцаў і
> навін. Спачатку трэба проста пачаць складаць такі changelog. Калі
> памер працы па інфармаванні сягне непрымальных межаў, аўтаматызуем.
> Але складаць changelog трэба так, каб да гэтага было проста вярнуцца.
>
> Арганізацыйныя задачы:
> 1. Распрацаваць структуру wiki. Я думаю, патрэбныя нейкія агульныя
> старонкі і праектныя. Адпаведна праектныя - тут праектам трэба
> думаць(паспрабуем перанесьці GNOME і Win7). А агульныя старонкі трэба
> абмяркоўваць. Вось з абмеркаваньня: “а) хто такія, б) што робім, в)
> навошта гэта робім, г) як робім, д) колькі чаго зроблена, е) што
> плануецца зрабіць, ё) што рабіць калі хочаш нешта зрабіць ды не знаеш
> як”, “галоўныя артыкулы -- кароткія нататкі аб тым як перакладаць,
> магчыма аб тым, як гэта цудоўна мець кампутар на беларускай мове і як
> сабе такое зрабіць (яшчэ адзін мануал пра як усталяваць лінукс)”. Мець
> на ўвазе ролі, і ствараць старонкі “для ўдзельнікаў”, “для
> карыстальнікаў”, “як з карыстальніка зрабіць удзельніка”.
> 2. Стварыць нейкі “monthly news”, і вызначыцца хто яго будзе пісаць.
> Ідэальна, калі changelog і быў тым monthly news, каб не трэба было яго
> вылізваць перад рассыланнем (а з перспектывы магчымай аўтаматызацыі да
> гэтага трэба імкнуцца).
> 3. Трэба сфармуляваць цяперашні workflow, правілы, нарматыўную базу...
> для наяўных праектаў і прааналізаваць, што добра, а што кепска. Потым
> можна з гэтага скласці рэкамендацыі для новых падпраектаў.
>
> Поспехаў,
> Ігар
>
_______________________________________________
I18n mailing list
[email protected]
http://mova.org/cgi-bin/mailman/listinfo/i18n