Clearly, multilingual support will be very important to a successful wiki. Will we have pages generated in one language and then translated to others, or do we expect unique pages to be developed in lots of languages? My guess is that we need to support both--core content will be translated and mirrored in many languages, while certain content (especially local projects, for example) will generate new unique content in their languages.
I've investigated briefly and found this possible approach to the problem: http://foswiki.org/Extensions/TopicTranslationsPlugin I also strongly support Regina's earlier points, especially regarding the licensing of content community members add. That may be something to add to the footer of each page in the wiki. One additional note below... -Ben On Oct 5, 2010, at 6:38 PM, Christoph Noack wrote: > Hi Benjamin, > > great collection :-) > > Am Dienstag, den 05.10.2010, 07:38 -0400 schrieb Benjamin Horst: >> I agree that overthinking and overburdening a wiki with rigid process is >> harmful, but some upfront organization and planning is still necessary. > > Yes, rigid processes are harmful for a wiki - even if they want to > achieve something good. But as you already point out, I'd like to guide > some people initially, to not get lost. If one doesn't find information, > then it is like nobody ever published it :-\ > >> Some major sections that could be defined in the wiki: >> >> - Site Home (why not use the wiki for the main part of the site, including >> the homepage and download page?) >> - Documentation (bring this dynamic and enthusiastic group back home to the >> main site) >> - Development (public planning and release schedule) >> - Community Council (private section, if desired) >> - News > > Just a question: Do you expect news to be in the Wiki, or on the rather > website? Or both? I'd like us to consider using the wiki for the website, or at least for a large part of it. (My comment above, "why not use the wiki for the main part of the site..." was meant to convey that idea.) Regardless of whether we decide on using the wiki for the main site, I think a strong case can be made to use it to manage our News page. (I would not recommend duplicating content, News or other, on both the wiki and separately elsewhere on the site. We should ultimately choose just one location, wherever it is.) > >> - Events >> - Marketing and Advocacy >> - Design and Artwork >> - Teams and Projects > > By the way, I really like the idea of Special Interest Groups at Fedora. > >> - More? > > Most presumably yes :-) So thanks for the great start! > > >> Adding to Christoph's list of other project wikis: >> >> * Mozilla >> https://wiki.mozilla.org/Main_Page >> >> * Ubuntu >> https://wiki.ubuntu.com/ > > Interesting, Ubuntu seems to separate the official Documentation (Wiki) > and the "do the work" wiki. > >> * Foswiki >> http://foswiki.org/Home/WebHome > > Mmh, din't knew that. Thanks! > > > Benjamin, thanks for the comments ... most appreciated! > > Christoph > > >>> Cheers, >>> >>> just my 2 Cents: >>> >>> On Monday 04 October 2010 23:54, Christoph Noack wrote: >>> >>>> ... >>>> Step forward, and share your thoughts, >>>> too, please! But how to get started ... I mean ... without a wiki to >>>> document the statements. >>> >>> A wiki is a wiki is a wiki - so just set one up and let it >>> self-organize. Do not define too much contstraints in advance. >>> >>> Do not define too special rules in beforehead but rather let them >>> evolve. >>> >>> People in free projects tend to be very constructive, so let them do >>> their work. >>> >>> The final decision which wiki engine to take should be made by the >>> prospective core admins (as they will have to handle it). A bad engine >>> with a good admin is far better than a good engine with a poor admin. >>> >>> Rules should be made only _after_ a certain period of experience. And >>> they should be defined by the users of the wiki. >>> >>> All that said, I'd prefere to have a wiki farm for different languages >>> and not one multilanguage wiki - just to enhance usability (mainly the >>> search function). >>> >>> Nino >>> -- Benjamin Horst [email protected] 646-464-2314 (Eastern) www.solidoffice.com -- To unsubscribe, send an empty e-mail to [email protected] All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
