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

Прывітанне.
Мы з Алесем паспрабавалі сфармуляваць тое, што ўжо выказвалася. Можаце
яшчэ дзень-два памеркаваць, а на выходных пачнем інсталяцыю ўсяго
майна на сервер і арганізацыю старонак. З тэхнічнымі пытаннямі мы самі
разбярэмся, а вось калі ёсць ахвотныя дапамагчы з задачамі пункту
"Арганізацыйныя задачы" (унізе), запрашаем да ўдзелу. Праз тыдзень-два
рэсурс павінен збольшага функцыянаваць.

===

Мэты:
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