Michele Zarri wrote:
I will start from the translators bit.
The Italian localization team is using a program called OmegaT. With
this program (and I guess also with similar ones, one of the great
advantages is that when an original document is updated, it is
relatively simple to update the translation as OmegaT will show what
the new sentences are.
Yes, it's great, but for updating the translation.
I need all the chapters for 2.2 apart from those referring to 2.1 and
2.3 because when i translate (in Romanian, and i'm the only one who is
doing this, so it takes a lot of time) i need all the chapters referring
to the same version of software. I cannot write a book with some of the
chapters for 2.2, some for 2.3 simply because when i started it was 2.2
in place, when i finished oooaut was working at 2.3. OK, i can make
myself a copy of the guide at the beginning. But let's take a snapshot
now (or in 3 months time): some of the chapters will be for 2.2, some
for 2.3 because you already started working for 2.3 version, and, untill
all chapters are updated, there will be a mix. Which mix is not suitable
for translation.
Regarding tracking the versions in the user guide, I am not sure I see
the need and it creates a big overhead although we may want to
consider it for version 3.
It is not that big. Simply when someone is updating for the new version
will make a different folder. It will also be a simple way of looking at
what chapters have been updated and which haven't. The only overhead
will be for Jean and the others maintainers, because they'll take the
*.odm and the missing chapters from a different folder.
Also, probably people will be less enthusiastic to see an almost empty
folder, but we can give it a try.
Similarly to what you wrote, what we need in my opinion is a kind of
user guide issuezilla where we could capture:
- "Roadmap" items i.e. improvements made to the program that are not
captured in the user guide. When a version of OOo is released,
normally it comes with a very comprehensive list of what has been
added. all we need to do is for people who are familiar with the
contents of the User guide to check what should be added and create an
"issue"
- "bug" items i.e. typos, wrong procedures...
- "Request for enhancement" items, i.e. topics that are not adequately
covered or not covered at all in the user guide.
That will be a good idea, provided that the system will be very easy to
use. 'Till then who is interested may check the chapters vs changelog
and compile a list of todo's (eventually posted here). The checking must
be done no matter what the system will be.