[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n
Subject:    Re: Getting Documentation to Work in i18n...
From:       Eric Bischoff <ebisch () cybercable ! tm ! fr>
Date:       1999-01-02 11:02:23
[Download RAW message or body]

On Sun, 27 Dec 1998, Stephan Kulow wrote:
>Patrick D. Dowler wrote:
>> 
>> >The installation directions for KDE would then become to install:
>> >        kdesupport (whatever you need from there)
>> >        kdelibs
>> >        kdebase    (includes ksgml2html ... )
>> >        kde-doc-<lang1>, kde-doc-<lang2>, ...
>> >        <other optional modules.>
>> 
>> I like this idea a lot. It would be great to be able to chose 1 or
>> more langauages udirng install and just get those. It  eases the
>> burden on ftp or cvs distribution of docs alot.

So : let's do it ! No ? Who could do that ? Peter ? We should hurry up, since
KDE 1-1 is nearly ready...

>> As an aside, the kcontrol thingy where one choses the langauge should
>> still show all the available langauages and mark some as "not
>> installed" - this helps users to know that some option could be
>> available and just  needs to be installed.

Fine, but this implies some program development, no ?

>> In langauge paks, the source should just include sgml. People
>> who make distrubutions can decide if they want to generate
>> the html and or ps for their customers if they like.
>> 
>Do we want to get rid of HTML in CVS? This would be a compromise
>for getting the i18ned docs back in sources ;)

It would be nice to remove HTML from the "applications" part of the CVS tree.
As an advantage, no one would attempt to write his/her doc in HTML anymore ! ;-)

But I don't want HTML to be suppressed in the packages kde-doc-<langn> that
would be distributed. Don't forget that kdehelp needs HTML files to work !

I don't want either HTML to be removed from the "documentation" part of the CVS
tree either, because :
a) end-users can read the doc on the web server
b) it is a fine tool for controlling our translation work with just a web
browser

So, I suggest :
- Applications tree : SGML
- Documentation tree : SGML, HTML, PostScript
- Packages : HTML, PostScript

The developper writes the SGML source, the translators translate it to their
respective languages and publish it under two formats, and end-users get those
two formats for browsing and printing.

>What the above doesn't say, is that we have currently 30 languages.
>So: you can have 30 doc packages per source module or have one doc
>package for _all_ applications, but this would be what you don't
>want (as do I).

Well, I would say this is no heavy burden with respect to all the titanic work
Chuck and all the teams leaders and all the translators are already furnishing !

>I think, we need to get rid of all those doubled files in CVS. Those
>logos are soo much redundant, that it hurts.

Yes, our favorite WebMaster (Hi Robert !) should make all the links to
logotp3.gif point to the Images directory, or better to a gif file for each
language (to accomodate separate packaging). 

But maybe this implies some modifications in the SGMLTools scripts ???

> A nif file and a SGML
>file and the application pictures should be enough in CVS, but then
>everyone would have to install sgmltools just to compile KDE out of
>CVS... Not sure if I want that.

If we adopt the scheme I proposed earlier in this message, they could dowload
the HTML archives from the web server

>But what we do in CVS is not necessarly what we need to have in
>packages.
>And what we do in tgz is not necessarly what we need to have in RPMs or
>DEBs. 

Right. Again, I think that SGML is enough for applications CVS, but that HTML
and Postscript should be kept on the web server (don't forget that it can be
accessed through CVS as well).

>I need opinions - I can't currently imagine the pros and contras enough
>I'm afraid ;(

Eric
--
Eric Bischoff
mailto:ebisch@cybercable.tm.fr

[prev in list] [next in list] [prev in thread] [next in thread]