Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


Hi David, *,

On Fri, Nov 12, 2010 at 7:20 AM, David Nelson <commerce@traduction.biz> wrote:

Following on from the conference call last night, IMHO it would
facilitate things for many people if someone with experience with
SilverStripe could set-up a default IA/framework of empty pages
covering our initial needs,

No need for having experience - everyone can hit the "create page"
button, and everyone should understand the metaphor of a explorer like
tree for the relations between pages.
But that aside, the problem is of course to come up with the concrete
items that should be put on the site *now* - and not come up with
items that might be on the page somewhere in the future.

and then replicate that framework for each
language.

No - stop! :-)
The framework wouldn't need to be replicated, as those items are meant
to be available at the main site, and thus of interest for all
languages. So the translations should be provided at the main site,
not in the corresponding NL-Subsites.
So when the structure is setup in en-US, then you can use the
Translations tab to add translations.

 That way, content authors can just start writing into the
previously-prepared pages, without having to worry about designing an
architecture.

Well - if they have content to put up, they can prepare it with
whatever tool they're familiar with and then provide just the content
for someone else to put on the site.
And of course if someone already plans to create a site with a
specific topic, then state so here. Then it is easier to add the
placeholder pages.

Then they submit their ready pages for publication, and
the site admins can finally publish the pages online.

you can enter stuff into silverstripe without being ready for
publication, just save, but don't publish and it will not be viewable
by regular visitors.

"Workflow" can be regulated simply by posting a set of rules and role
descriptions on the wiki. That will avoid the need for complicated
configurations of permissions, etc.

The user doesn't have to setup permissions, the user just states "I
want to work on this or that subsite" - that is exactly why there are
admins after all.
Setting up permissions is only needed when a new subsite is created.
After that it is just adding people to the corresponding group on
request.
And I'd not call this workflow.
Workflow is how the user interact with the system - i.e. either they
publish themselves (short-circuit the workflow), or they request
publication and have another publisher handle the request (handling
could be just commenting, approving, denying, canceling)

It's true that different lingual communities might need some specific
pages. That can be handled by creating one top-level page that can can
be a root for the sub-pages that each lingual team can then create.

Nonono, that's not how the structure works in my idea. Technically it
is possible, but it shouldn't be the desired outcome.

Again: Content for all users, no matter what language
→ end up on [www.]libreoffice.org
on [www.]libreoffice.org, those content can be provided in different languages.

Content specific to a NL-group should en up on <lang>.libreoffice.org

Here on this thread, we can just gather suggestions for the "outline"
to adopt, over the next 24-48 hours. Then, after that, each lingual
team can debate among themselves about the actual draft to insert in
each of their pages.

See above/the other post - this is then handled using the translation
feature. When no translated page is available, it would just default
to the english on one www.libreoffice.org

This way, we could get a site up and running quickly.

The site is already up and running (even running quickly :-))

IMHO, I think we
need to keep things simple, and not to aim too high in terms of
technical design/implementation work.

Again: The technical aspects are settled for a loooong time already.

I still don't really get why people keep mentioning silverstripe or
the technology with this topic.

Defining what pages, what content to put up on the site is not
depending on technology, neither on silverstripe, neither on drupal,
neither wordpress. Neither would it be with a manually maintained site
of individual html files.
On the contrary, using a CMS makes it easier to just put pages to
another place when the place it was originally created at doesn't seem
appropriate anymore.

But I'm distracting - I propose to crosspost this to all appropriate
(website, marketing, l10n - any other list?) It should be sent today,
so please provide feedback until 18:00 UTC

Help creating the initial content of libreoffice.org - in terms of
structure and content

Hi *,

soon the libreoffice.org website is meant to be moved from the
temporary test.libreoffice.org name to libreoffice.org - but at the
moment we're lacking a structure and content.

So please chime in and provide input (possible within the next
48hours) to kick it off.

What is needed:
* A structure that can be filled with content quickly (release of
final version is not too far away).
  No future ideas/would be nice to have items, but stuff that are of
relevance now.
* content to fill that structure with life

As it has been indicated at several places, people are unsure where to
put stuff, what stuff to provide. An empty set of placeholder pages
would help those contributors, provide guidance for all.
And of course if you have appropriate content already up your sleeve -
just provide it. If you don't want to put it up on the site yourself,
then post a link, paste the content to a mail and send it off to the
website@libreoffice.org list and someone else will put it up.

What about localized content?
* The focus should be in defining a structure for the globally
relevant stuff at first. The pages at [www.]libreoffice.org should be
relevant for all users of LO, no matter what language they speak.
That being said, it is of course possible to provide translations of
the content on [www.]libreoffice.org - that content will then be
linked directly, no need to manually maintain a list of available
translations - and for pages where no translations are available, a
fallback to the english content will occur.
* If you have globally valid content created already in your language,
this should be copied to the main [www.]libreoffice.org site [1]
* content that is of relevance only for one specific NL-group should
be put on the <lang>.libreoffice.org subsites

How would I get access to the CMS system to provide the content myself?
* register an user account at
  http://www.test.libreoffice.org/ForumMemberProfile/register
  (https is also possible, but as it is for documentfoundation.org,
you might need to add exceptions to your browser)
* Send mail to the website@libreoffice.org mailinglist in order for
one of the admins to grant you access

This sounds complicated/I don't want to use the cms
* in case you want to give feedback on the website's structure, reply
to the website@openoffice.org mailinglist
* Regarding content: Create it as plaintext or add it to the wiki or
some other site, then post to the list asking someone else to add it
to the CMS.

ciao
Christian

[1] to use this site from within the NL-subsite, you can setup a
"Subsite VirtualPage" that internally links to the site ans will make
the content available on your subsite as if it was part of the subsite

--
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.