[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Putting lenny release notes on www ASAP?

On Sat, Nov 22, 2008 at 11:55:48AM +0100, W. Martin Borgert wrote:
> On 2008-11-22 11:04, Jens Seidel wrote:
> > Right. Nevertheless one checks normally only the trunk version out. I think
> > it would be a good idea to switch to trunk as soon as working on a new
> > release starts. This simplifies contribution a lot.
> Yes, I agree. The branch was meant temporarily.

The current stable version can later be moved to a branch to save it's state.
> >  * Currently the suffix .dbk is used for DocBook/XML files. Is this a usual
> >    one? Other documents I know use .xml which I prefer. (That's only a minor
> >    issue but once the code is moved to trunk one can fix this as well.)
> I very strongly prefer .dbk over .xml. XML is very generic
> (everything is XML nowadays, right? gnumeric, dia, abiword, ...)

> >  * Currently multiple PO files are used. One for each English document.


> >    I think a single PO file is much preffered.
> OK, I have to check, how to handle this. Currently, it makes the
> build process a little bit easier (and more aligned with the
> languages, where po is not used on request of the translators)

Trust me that a single PO file for each language is not more difficult.
The opposite is true: Since two different files could share strings they
need currently to be translated multiple times.

> and it allows translators to easily share their work without
> having to merge later.

Partly. How to share 5 files with 10 translators :-?

> But we can change this, if you prefer.

If other people do not agree there is no need to change it. But dealing with
a single file is just easier.
> >  * In my older build I still found the strange filename en/release-notes..pdf.
> >    Nobody noticed it yet? This will clearly make trouble once we link to this
> >    file from the website. Maybe it is accessible via language code "" or ".".
> This happens, if the "architecture" variable is not set during
> the make run. I will change the Makefile, that this does not
> happen anymore. Sorry for the inconvenience.

The old Makefile displayed an error in this case ...

Reply to: