[Mageia-discuss] Website software

[Marc Paré]

Le 2010-09-21 19:09, Romain d'Alverny a écrit :
> 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
> proceeded);
>   - 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).
>
> Cheers!
>
> Romain

Merci de ton explication Romain. Are you then going to be involved with 
the web design of the site(s)?

Marc