Re: The wgo CMS can't wait more

[Marc Laporte <marc marclaporte com>]

Quim Gil wrote:

> As a matter of fact I think we can get a decent wgo with the 5 tools, in
> an ideal world with no time constraints and a good team of savvy CMS
> hackers. But we need to end up with one tool, the one that brings the
> best results with the minimum headaches for the type of website we want.
>
> Tiki. I think it's more than a good wiki tool and my friends using Tiki
> are in love with it. I agree with Marc that we could have a wgo based on
> Tiki (not looking like 90% of Tiki sites) but I have some reasons to
> think it can be dismissed for the wgo revamp:
>
> - Localization. http://tikiwiki.org/tiki-index.php?page=MultiLingualDev
> is pretty much what we and many multilingual sites are looking for.
> Marc, you seem to be behind these good ideas (congratulations!) but as
> far as I see they are ideas by now, no working code. Without this I
> don't see an easy way to integrate and maintain multilingual sites with
> a good coordination between languages. 
>  

Yes, I agree. This is the only point which I feel Tiki doesn't fully 
meet the requirements. Just to be clear (that WGO is comparing apples to 
apples):

Articles and wiki pages can have 0 to n translations.  For articles 
(news), this is easy because article #72 is the Japanese version of 
article #32, in English. Once published, the news articles are not meant 
to change. Multilingual articles demo here:
http://gnome.rclaporte.com/tiki-read_article.php?articleId=1

So when a news article is published in English, all translators receive 
an email. All translators are assumed to understand English. If not, 
they wait for a language they can read. They login, they add 
corresponding article.  End of story. This works for press releases, etc


Tiki 1.10 even has a new Interactive Translation feature (written by a 
guy in Switzerland!) so translation of menus (not just content) can be 
done via Web Interface. This is pretty cool because it lowers the 
barrier to participation. It also permits people to translate these 
short text strings while being in context.
http://gnome.rclaporte.com/Interactive_Translation


Where it gets tricky is for wiki pages (ex.: documentation, FAQ, etc). 
While it is easy & supported to have any number of corresponding wiki 
pages (You can see it in action on doc.tikiwiki.org), the missing part 
is good coordination between languages, for translators and visitors.

I have given this a lot of thought. I have done a fair bit of research. 
This is a feature I want added to Tiki. I am not too worried about the 
programming part (all the basic blocks are there).  It is the logic & 
the interface. I can see it working for two languages (where you lock 
changes to a page until the translation is back in sync). But I have yet 
to grasp how to have something workable (simple enough but not too 
simple) & scaleable in more than two languages.

So I repeat my question from August: "Can someone point me to a working 
implementation (in any open source CMS)?"
http://mail.gnome.org/archives/marketing-list/2006-August/msg00108.html

My interest in this matter goes way beyond this current discussion. I 
manage several multilingual projects. In many cases, we don't have the 
resources to translate everything and to keep it in sync. I am hungry 
for a better tool! This being said, with community discipline, we can 
get by with the current toolset.

Here is the issue revisited recently:
http://drone-alliance.org/wordpress/2006/08/20/i18n-revisited/
You will see it can become very tricky with branches & all! Which type 
of contribution invalidates the translation set, etc

Back to WGO, I also got confused when someone on the list was insisting 
to use PO files. So does WGO want PO import/export or should 
contributors edit via the web-based interface?




> - Look&Feel. Did you see the mockups at
> http://live.gnome.org/GnomeWeb/LooknFeel ? They are not the final but
> they are is consolidated enough to show what's the plan. Considering
> Tiki's theming capabilities and also the functionality to have a
> customized home page, perhaps we could get there. However, I think it
> might take us a lot of work. But well, it is also true that whatever the
> choice is theming will be one of the major tasks.
>  

Thank you. No, I had not seen.

It will take you zero work because I have volunteered to integrate from 
html to tiki templates. :-)

> - Learning curve, documentation, support. Tiki is in good condition
> here. It seems a system easy to learn and I think we would get support
> at several leves from you and the Tiki community in general.
>
> - Security and upgrades. I don't have enough information to evaluate
> this.
>
> - User management is ok- I don't have enough information to evaluate the
> user integration with other systems, but it's not essential.
>  

Tiki is excellent here. LDAP, CAS, HTTP, PAM (and Shibboleth in 1.10) 
Support was recently added for pop/imap server. We use Pear:auth so 
adding more is easy :-)
http://pear.php.net/package/Auth/

We also have InterTiki which permits to have a master userbase, and 
slaves. The slave sites can inherit groups and settings from the master 
site. One nice central user system. and the satellite sites have 
different permissions per Tiki installation. This is how we manage 
satellite community sites (doc.tikiwiki.org, themes.tikiwiki.org)
http://tikiwiki.org/InterTiki

> - Contributors around. Marc has been helpful and proactive since the
> minute he knew about the wgo revamp. I have no doubt he would help if
> Tiki would be chosen. However, I'm concerned about the (apparent) lack
> of experienced Tiki admins around us. 
>  

Understood. But it's fairly simple. Many people install via Fantastico. 
And can do all the admin tasks via the GUI.

> For all these reasons I think that being Tiki a very complete tool, it
> is probably not the most appropriate option for wgo. We would need to
> hack a lot of current functionality while not using most of the great
> features Tiki has. We could say it's a nice shoe for another foot.
>
>  

Understood.

If you change your mind, and would like a template integrated or 
anything else, please let me know :-)


> If we agree on this, we will move for a next candidate to be dismissed.
>
> In any case, I want to thank Marc for his patience and willingness to
> help. Respect.
>
>  

You are most welcome. Good luck!

Best regards,


--
M ;-)

//////////////////////////////////////////////////////////////////
/                                                                /
/ Marc Laporte       <|>                  http://marclaporte.com /
/ Avantech.net       <|>                     http://avantech.net /
/ Tiki CMS/Groupware <|> http://tikiwiki.org/UserPagemarclaporte /
/                                                                /
//////////////////////////////////////////////////////////////////