[CREATE] Fwd: Re: [LGF-LGA] Ok, let's start with a website

Camille Bissuel cbissuel at yagraph.org
Thu Aug 12 10:10:21 PDT 2010


Hi,

Honnestly, Spip is good on i18n... but it's very old. At least templating is
a real mess, and I often experience caching problems with spip websites.
I'm very interested in Anwiki... wiki + i18n optimisation seem to be what we
need. If we consider the Aïki framework wich is quite young, why not Anwiki
?

On Drupal, my website (www.yagraph.org) is based on Drupal 6, and I never
succeeded to set up i18n correctly despites my efforts (I gived up). Maybe I
can try again...
Can you be more explicit on the Drupal tools ?

More and more, It seem that a "cms-oriented" wiki is a good idea...
Mediawiki is well know and robust, but I'd like to know more an Anwiki.

In my point of view, intersting candidates so far are Mediawiki, Anwiki,
Aïki and maybe Wordpress.

Going on...
-- yagraph



2010/8/12 Yuval Levy <create07 at sfina.com>

> On August 12, 2010 05:18:01 am a.l.e wrote:
> > what i've read should be ok for multilingual sites is spip. has anybody
> > something against it?
>
> I don't know spip but I have done extensive research about CMS for
> multilingual sites a couple of years ago and the best one IMHO was Drupal
> (v6).
>
> "multilingual" is often interpreted in two different ways: the *silos
> approach* and the *atomic approach*.
>
> The silos approach is the more common.  The underlying assumption is that a
> user will enter the site in one language and stay in that language.  All
> there
> is to multilinguism are links to the entry point of the website in the
> different languages.  This has negative effects on maintenance (each
> language
> site tend to get a life of their own, with some being more up to date than
> others) and on search.  Especially when the subject matter has specialist
> terms in a particular language (English in our case), alternative language
> content tend to be underrepresented in search results.
>
> The atomic approach is technically more demanding, but fixes the above
> mentioned search problem.  Ideally translation/language links are made at
> the
> individual content element level;  translators are helped by a list of yet
> to
> be translated content; there is a fall-back sequence toward the front end
> so
> that users navigating the site in a language that is not completely up to
> date
> get to seamlessly fall back to another language.
>
> I see the atomic approach on Wikipedia ([0] vs. [1], see the list of
> languages
> on the right which seems to be dynamically generated depending on whether
> the
> content is available in that language or not) but I do not know how this is
> implemented in the MediaWiki software.
>
> Back then, I found that Drupal offered all the necessary tools to manage a
> multi-language website with atomic approach.
>
> HTH
> Yuv
>
> [0] http://en.wikipedia.org/wiki/Inkscape
> [1] http://en.wikipedia.org/wiki/Scribus
> _______________________________________________
> CREATE mailing list
> CREATE at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/create
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/create/attachments/20100812/fa32b37b/attachment.htm>


More information about the CREATE mailing list