[scribus-dev] Scribus documentation translations temporarily removed from builds
christoph-schaefer at gmx.de
Sun Nov 28 09:12:40 CET 2010
On Sunday 28 November 2010 12:32:11 Louis Desjardins wrote:
> 2010/11/9 Craig Bradney <cbradney at scribus.info>
> > On 09/11/2010, at 8:01 AM, "a.l.e" <ale.comp_06 at xox.ch> wrote:
> > > hi christoph,
> > >
> > > as i've already stated i feel a urgent need to see 1.4 released.
> > >
> > > the documentation is certainly an important part of the scribus
> > experience, but -- to me -- in the current state of the project, the team
> > should focus in getting a stable code out and working.
> > > so, my reaction: hopefully this effort won't affect any other task!
> > >
> > > i'd really love to see a planned release 1.4.1 which will follow short
> > after 1.4. with all the updated documentation, the new color palettes and
> > other goodies which make scribus more shiny but are not affecting the
> > scribus core functionality.
> > > and if parts of the doc are too outdated, simply remove the parts which
> > don't fit and add it again into 1.4.1.
> > > just my 2c
> > >
> > > ciao
> > > a.l.e
> > Hi
> > Since when did Christoph code, never, so why would this affect Scribus
> > code?
> You are right on that point but the issue Ale is raising is will the doc
> update slow down the release of 1.4?
Short answer: No.
Longer answer: Documentation updates will be added when they are ready to be
included. This process can continue during the whole life cycle of 1.4+. The
same goes for translations.
> We have this bug in the bugtracker:
As you can see, the bug is assigned to Peter, who is another person that
> I share Ale’s view that we should not refrain from releasing 1.4 even with
> an outdated documentation.
Please repeat after me: The documentation update is not blocking the 1.4
release. It's some ugly bugs that are.
Personally, I'm against releasing 1.4 just for the sake of a release, no
matter how much pressure some users are trying to impose on the team.
> Of course this is debatable. The point here is if the doc updating pace is
> not following closely the code pace, should the code have presedence? I
> think that yes. This does not mean I don’t believe we should have a strong
> doc. But it can be updated downstream. And opened to translation.
> I also take the opportunity to open a discussion about the importance of a
> hard copy Scribus Official Manual considering what happened with the first
> edition. I think the doc should be entirely dynamic and as close as
> possible to the code. This can be achieved in various ways but the online
> help is certainly one way to go. If someone wants to have a printed copy
> then we could manage to find a way of exporting the data to a Scribus
> template that would be printable. I like books. But I do not support the
> idea of a printed Official Manual anymore. We need to concentrate on the
> content and make those files available for translation asap. This is a
> real need. We can have support for this. Anyway, I am always opened to be
> convinced of the contrary. But let’s not slow down the releae of 1.4.
There will be a second edition of the manual, but this time we will select our
publisher more carefully. The printed manual will be different from the Online
Help, although there will be some overlaps, and I'm even considering cross-
referencing between both kinds of documentation.
A printed book has some real advantages over an Online Help for many users,
and it's also good for the reputation of the project.
Again, creating the book does not and will not affect the development of
Scribus itself, except for helping to unearth bugs, as it did the last time.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scribus-dev