[Mageia-discuss] Website software

Romain d'Alverny rdalverny at gmail.com
Wed Sep 22 01:09:20 CEST 2010

On Mon, Sep 20, 2010 at 05:11, Diego Bello <dbello at gmail.com> wrote:
> I think Romain has a lot to say here.
> He knows the needs of the current Mandriva site so he can say
> if the best option is a CMS or a custom developed site (Symfony anybody?).

Well, yes and no. I can mostly relate what choice has been made at the time.

We got several experiences with some CMSes that were not so good in that:
 - web team was way too small to master the whole thing;
 - editing pages was restricted by a limited set of templates;
especially, a CMS could now allow to edit inline HTML, so fine-tuning
the contents layout was a no-go;
 - its ease-of-use for non-technical people was supposed to distribute
editorial responsibility within the organization; in fact, very few
people did it themselves, rather sent a mail to the webteam to
integrate an open office document;
 - its ease-of-use was too to help for translation process; that was
partly true, it helped yes, to some extent (too small a team being the
culprit, he, but making this way harder to manage in the end);
 - no dedicated or available skills to maintain it (so many nightmares
to fix common issues or upgrading it);
 - performance issues under heavy loads;
 - no apparent content strategy from one migration to the other
(broken links & redirection all around; missing contents; inconsistent
design across the whole domain, etc. but that's another topic, yet).

Not that I am complaining. These were great times and there were lots
of good things to learn from these CMSes too (maybe not stable enough
at the time or not properly mastered) but that was what was
experienced. Goal was to improve on this.

> I think the most important feature here is internationalization, cause
> Mageia really needs to show itself to the world, and let me tell you
> the world doesn't speak English only.

Indeed. Now you have to take into account several things:
 - you've got to decide whether you use a pivot language content tree
or leave several language trees evolve on their own; that is, having a
reference from which you translate/adapt everything, the process being
more or less fast depending on your translation team; or, having an
mutual agreement between all editors, and moving each language tree to
its own pace; for a start, I would suggest the former (ie, having a
reference tree to translate from), then adapt;
 - translating, better, localizing a web site is not about only
translating chunks of text; you sometimes need to rework pictures,
labels, layouts, add/remove specific contents; so it may require
several basic webmastering skills (editing HTML, working on graphics,
understanding and coding CSS, bits of Javascript and so on);
 - you've got to decide if you strive for a standard-looking website
or if you want to apply a specific look and be able to fine-tune
everything; again, that depends on your "global" web team capacity of
production and maintenance;
 - coordination of the localization process of the website is a huge
task in itself;
 - all your website does not necessarily have to rely on a single
solution; you can have a blog platform here, a static set of files
there, a drupal over there, a forum here, ad-hoc download platform
there, etc. it really depends on several parameters;
 - questions to ask are: what does Mageia do? why? how do we organize
all this information? who produces/uses it? what should be the
user/visitor experience/goal? what's the best tool for that?

Now, back at the time (it was first drafter in early 2007 and went
into prod in the fall of 2008), I wrote a very basic "decorator" web
framework that let me build and design standalone HTML/PHP pages
(against a set of CSS rules and a minimalist theme, to be revamped
later with a graphics designer - didn't happen, sadly) in the old-way:
files and directories. All this was versioned on a SVN (crucial part
of the system) to allow for collaborative webmastering (I wouldn't
call that editing as, again, it's not just updating chunks of text).

This was only for the main "institutional" website (aka www/www2)
where things are pretty static (a big update every 2 months or so,
plus gradual improvements in the meantime). Around this connected a
blog, a news feed (that could have been a blog), forums, wiki,
support, download, e-commerce platforms, etc.

It was far from perfect of course, but it was valid and working in
that context and back at the time because:
 - content was mostly static; few areas needed to have dynamic
behaviour, and when it did, a small ad-hoc webapps system was
available to take on that job;
 - so you didn't really benefit from having a database;
 - it proved effective for deploying a standard look to most of the
distinct platforms, all from a single web service (top nav bar + basic
CSS rules);
 - présupposé was that only webmaster-skilled people would manipulate
it; and it would keep it away from people that would not care at all
about the website global consistency (about information architecture,
design, navigation, localization, content strategy, etc.); that was
part of my job, actually;
 - experience with Blogdrake translation team proved it more fluent
than a conventional CMS (or so I thought), although there were lots of
improvements to do (especially in direction and how we would have
 - there were interesting improvements to find (because, well, it's
not an "ideal" solution), like, setting up a mixed templating system
to help formatting standard pages across all locales;
 - and in the end, because I felt more confident with a minimalist
solution I could understand and manage with other translators than a
big thing I couldn't;
 - and it wasn't as stupid as that as other big web projects seemed to
use a similar solution (which I learned through discussions that I
freely inspired from too) for parts of their website.

That was unpublished code, unfortunately (although it was in my
plans), so I can't publish it. But I can redraft it, as it's pretty an
easy architecture to reproduce and code is not that big. Most of the
work is still, well, in how you design and build your website. No tool
will write a good story for you.

Now, things may be slightly different:
 - I won't manage websites directly, but most likely coordinate and delegate;
 - you certainly have better ideas.

Sorry to be so long (ah, don't start me with that topic! ;-) ), just
to state what I learned and think is important to take into account.
You may want to use something like that too (or not).



More information about the Mageia-discuss mailing list