Re: [libreoffice-website] [SC] Decision about CMS

Le 2010-10-20 11:22, Andrea Pescetti a écrit :
> Sophie Gautier wrote:
> > Just to point that we need to handle i18n and l10n easily also, this
> > is important to think this multilanguage way till the beginning.
>
> Then I'll have to ask again what you mean by this!
>
> 1) Having translatable pages (meaning: an English about page at
> http://www.documentfoundation.org/about.html and its French translation
> at http://www.documentfoundation.org/about.fr.html or equivalent)
>
> 2) Having localized websites, with independent structure but same login
> (similar to how CollabNet is working now for OpenOffice.org)
>
> 3) Having both (not acceptable from my point of view, too confusing)
>
> Work on a multilingual site cannot start before deciding on this.
>
> Everybody who's been around for a few years in OpenOffice.org knows pros
> and cons, but to summarize them:
> - Option 1 makes it easier to monitor page changes, since you have the
> "English version" and the "French version" of a page linked in the
> system, and you can compare them easily.
> - Option 2 gives N-L teams more flexibility, since they decide how to
> structure their own site (from the diversity between N-L sites, I'd say
> this is rather appreciated now). So if the French team wants an About
> page, it will create it in their site structure; though, checking if it
> is up-to-date with respect to  the English version must be done
> manually.
> - Option 3 to me is just problematic, since you don't know where to put
> the French "About" page: in the global site as translation of the
> English "About" or in the French site?
>
> If I had to maintain the Italian section of the site, I would go for
> Option 2: Italian pages would be the ones the Italian community feels
> relevant for them, which can be different or in a different order than
> the global (English?) ones.
>
> Regards,
>    Andrea.

A lot of these options would have to take into consideration SC website 
philosophy. Do the SC members want a unified look and structure to the 
various sub-sections of the main English website; do they consider the 
localized versions as autonomous as to have their own website structure. 
The SC members would have to pronounce themselves on these points.

As a user, if find it extremely useful if the structure follows that of 
#1. If you are on the English site at: 
http://www.documentfoundation.org/about.html and seek out its Italian 
translated page, then you seek out the 
http://www.documentfoundation.org/about.it.html or then if you seek or 
the French translated page, then you seek out 
http://www.documentfoundation.org/about.fr.html. And so on for any other 
page. This allows for a very efficient mechanical structure. However, as 
you alluded, the structure may not represent the flavour/character of 
the localized pages. They merely represent the translation of the main 
English site. However, as a user, this structure makes is quite easy to 
navigate from one localized version to another. In this case the SC 
would hold a firm grip on the structuring of the website.

#2 Differs in that the localized section of the site is built by the 
community and would most reflect the flavour/character of its members. 
So the pages would not necessarily be present at the same location and 
some pages may not even be present depending on the communities. In this 
case, the SC would hold very loose grip on the structuring of teh 
website and the community would have greater participation in the 
structuring of the localized website.

So, there are 2 things to consider:

1. Does the SC wish #1 or the #2 option?

2. Can either Silverstripe and Drupal support either of these scenarios.

Opinions on #2 is the one that is really important for this thread.

Could the Drupal and Silverstripe give us their opinion on this? Could 
this scenario be supported by either package?

Marc


--
E-mail to website+help@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/website/
All messages you send to this list will be publicly archived and cannot be deleted