Am Sam, 2003-07-26 um 13.07 schrieb Roman Joost:

I cant find anything related to the gimp-help project at the newer webpage.

You're right. There isn't... :(

So, if someone could point me to a ressource regarding this project it would be fine.

Ressources:
- This mailinglist (there had been a big discussion here the last few days), you might want to check the archives - gimp-help-2 module in GNOME CVS
- Me

As far as i know, the gimp help is written in html and viewed with the gnome help browser.

Not quite.

The first version of the gimp-help was the HTML version of the book GIMP User Manual by Karin and Olof Kylander heavily modified to be usable for the online help.

The second version was a conversion (and extension) of the former to DocBook/SGML to gain flexibility regarding the layout, the output names, the output formats and get rid of the fairly static HTML cruft.

Now we're working on a third version which is a complete rewrite from scratch in DocBook/XML, mostly because the second version has some serious edges and drawbacks to what we would consider usable docs. You are encouraged to read about it in the file "STATUS" in the mentioned gimp-help-2 module.

Long story put short: A German version would be very cool and if you want to participate I'll help you getting set up. However since the English version is still quite at the beginning and the audience is much larger we need to find a few decisions before we start either a translation or a seperate documentation.

On 26 Jul 2003, Daniel Egger wrote:

Date: 26 Jul 2003 17:03:09 +0200
From: Daniel Egger
To: Roman Joost
Cc: Gimp Developer
Subject: Re: [Gimp-developer] writing german online help

Am Sam, 2003-07-26 um 13.07 schrieb Roman Joost:

I cant find anything related to the gimp-help project at the newer webpage.

You're right. There isn't... :(

So, if someone could point me to a ressource regarding this project it would be fine.

Ressources:
- This mailinglist (there had been a big discussion here the last few days), you might want to check the archives

the archives are either completely broken or just severely delayed. it is the 26 of July and the archive still does not show any messages for July.

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

Alan Horkan wrote:

On 26 Jul 2003, Daniel Egger wrote:

Date: 26 Jul 2003 17:03:09 +0200
From: Daniel Egger
To: Roman Joost
Cc: Gimp Developer
Subject: Re: [Gimp-developer] writing german online help

Am Sam, 2003-07-26 um 13.07 schrieb Roman Joost:

I cant find anything related to the gimp-help project at the newer webpage.

You're right. There isn't... :(

So, if someone could point me to a ressource regarding this project it would be fine.

Ressources:
- This mailinglist (there had been a big discussion here the last few days), you might want to check the archives

the archives are either completely broken or just severely delayed. it is the 26 of July and the archive still does not show any messages for July.

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

On Sat, 26 Jul 2003, Carol Spears wrote:

the archives are either completely broken or just

severely delayed.
^^^^^^^^^^^^^^^^^

it is the 26 of July and the archive still does not show any messages for July.

http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

try the url right above ^^^^^
that mail archives site, who knows where it came from, if i understand your problem correctly.

carol

That is very condescending, rude, and entirely unhelpful.

I checked the archives several times this week and I also checked them before posting my previous message. I checked them again just now.

July is still not listed. The search doesn't seem to work either

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

Alan Horkan wrote:

On Sat, 26 Jul 2003, Carol Spears wrote:

the archives are either completely broken or just

severely delayed.
^^^^^^^^^^^^^^^^^

it is the 26 of July and the archive still does not show any messages for July.

http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

try the url right above ^^^^^
that mail archives site, who knows where it came from, if i understand your problem correctly.

carol

That is very condescending, rude, and entirely unhelpful.

I checked the archives several times this week and I also checked them before posting my previous message. I checked them again just now.

July is still not listed. The search doesn't seem to work either

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

yes, please accept my apologies.

in the past, this problem was always with a different site that did better in google than the berkeley lists.

i am very sorry; i did not intend rudeness.

carol

On Sun, 27 Jul 2003 12:36:08 +0200 Roman Joost wrote:

But, this is not my main intention here - lets speak about german documentation. I figured out, that the gimp-help will now be written in docbook sgml.

Is there a Gimp document style sheet?

Owen

Am Son, 2003-07-27 um 12.36 schrieb Roman Joost:

Okey ... i did a fresh checkout from the gimp-help-2 module and get it to "work". I attached a 3 lines patch for the configure.in file, because i was wondering about a program called "no", which was used, if no xsltproc is installed on the system. Now its working fine for me and configure do the right thing for me. So, maybe i was a bit confused and fixed, which shouldn't be fixed - do what you want with the "patch" ;)

Maybe you forgot the attachment.

But, this is not my main intention here - lets speak about german documentation. I figured out, that the gimp-help will now be written in docbook sgml.

XML, not SGML.

What do you think, where should i start? Maybe i'll create a new de_DE directory and start writing ...

I'm not sure this is the best idea since it will be tricky to keep the English and the German version (at least to some extend) in sync. It's probably the best to combine all languages into the same file distinguishing the languages by lang tags. However I haven't thought much about this since you're the first to bring the topic up.

Are there any policies to follow?

- Don't mess with the structure
- the content needs to compile all the time (i.e. be valid DocBook/XML) - new content has to be submitted to a reviewer before committing (which would be me for German unless someone else steps up (Nomis, Sven, Marc, Mitch?))

I really can't imagine that there was no german manual or a something similar.
I hope, i'm able to change this ...

Go ahead. If you have anything toss it over to me and I'll get the Module the shape.

Am Son, 2003-07-27 um 14.46 schrieb Roman Joost:

Sure, but now its attached ...

Thanks, applied. I'm glad it works for you; I haven't received much feedback about it. What OS do you have?

Hm ... maybe the files will become really big after adding some different languages (e.g. de, cz ...).

Sure, but in that case we can still split them up a finer granularity on structure level, say: give every subsection it's own file instead of just every section.

I dont know if there is any standard to get the language of the system, but the $LANG environment variable seems a good start for me. So, guess this variable and select the right directory on start.

This is a nobrainer and not really related to the question how to organise the sources since they need to be compiled anyway (for now at least).

Am Son, 2003-07-27 um 14.25 schrieb Roman Joost:

In the gimp-help-2 module dir is a directory called "stylesheets" and the files in there, lookin for me like stylesheets. I think, yeh - there are document style sheets...

Yes, there are transormation stylesheets and some really simple CSS stylesheets.

Am Son, 2003-07-27 um 15.23 schrieb Roman Joost:

Thanks, applied. I'm glad it works for you; I haven't received much feedback about it. What OS do you have?

Debian GNU/Linux (sid - unstable)

Ok, no surprise that worked. :)

Or should the lang specified as an attribute? like: Optionen

It is an attribute which can be placed on any tag and (hopefully) in any depth. I'd suggest setting it on every first child of sect1s, i.e.

Welcome to The GIMP Willkommen bei GIMP

The GIMP
Introduction



GIMP
Einführung



...

Have a look at the current CVS version, I translated a few parts for instance in introduction.xml and added the mechanics for the German translation, so if you type make you'll get two directories in C/ plainhtml and plainhtml-de.

Please note that every tag not qualified with a language attribute will show up in all languages and content which is qualified in sect1 childs but not translated will show up as empty sections in the index.

Also the profiled version spits out some useless warning but apart from that it works fine.

Daniel Egger wrote:

Am Son, 2003-07-27 um 12.36 schrieb Roman Joost:

Okey ... i did a fresh checkout from the gimp-help-2 module and get it to "work". I attached a 3 lines patch for the configure.in file, because i was wondering about a program called "no", which was used, if no xsltproc is installed on the system. Now its working fine for me and configure do the right thing for me. So, maybe i was a bit confused and fixed, which shouldn't be fixed - do what you want with the "patch" ;)

Maybe you forgot the attachment.

But, this is not my main intention here - lets speak about german documentation. I figured out, that the gimp-help will now be written in docbook sgml.

XML, not SGML.

What do you think, where should i start? Maybe i'll create a new de_DE directory and start writing ...

I'm not sure this is the best idea since it will be tricky to keep the English and the German version (at least to some extend) in sync. It's probably the best to combine all languages into the same file distinguishing the languages by lang tags. However I haven't thought much about this since you're the first to bring the topic up.

Are there any policies to follow?

- Don't mess with the structure
- the content needs to compile all the time (i.e. be valid DocBook/XML) - new content has to be submitted to a reviewer before committing (which would be me for German unless someone else steps up (Nomis, Sven, Marc, Mitch?))

I really can't imagine that there was no german manual or a something similar.
I hope, i'm able to change this ...

Go ahead. If you have anything toss it over to me and I'll get the Module the shape.

just for me, can someone count the contributions from everyone to the gimp-help that is there and working?

if we start doing the same thing again, i don't know. it is hard enough right now to type comprehensible email about it.

i learned history so that i do not repeat it. i learned that the opinions of the people who set the systems up are crap and the opinions of the people who use the system are all that matter.

you run down failing pathways. i cannot go with you. do the people contributing or trying to contribute get a say?

Roman, i invested money to learn docbook, i suspect it was to keep up a broken system and broken people. i would send you $5 to try to rid yourself of this dependency on docbook, at least for your own sake, try to get a better deal for yourself from prof and docbook authors.

i think it destroyed syngin. syngin was beautiful. look at the commit list.

what is a good and proper way to say "Something stinks so badly and i suspect it is ." and not piss anyone off and be clearly understood.

carol

Am Son, 2003-07-27 um 16.45 schrieb Carol Spears:

you run down failing pathways. i cannot go with you. do the people contributing or trying to contribute get a say?

Sure they do.

[ Absolutely useless rant deleted ]

I've no idea what happened to you in the last months but whatever it is, you REALLY should try to get that fixed before you hit the ground in everyones killfile.

Having said this if your next mail contains as little information and as much FUD as the previous 30, I'm not going to reply anymore. I'm thouroughly sick of this crap!

Am Son, 2003-07-27 um 19.16 schrieb Roman Joost:

1. The German Umlauts are really annoying. Are there some pre-processors, which checks the umlauts and replaces them with an utf entity (or the predifined HTML umlauts... what else...)? If not, it think i'll write a little script. I forget them every time...

Hehe, and you even introduced a typo by trying to fix one of mine. :) Try to convince your Editor to map Umlauts to HTML Entities and you're done.

2. How do i create a better patch? I tried: cvs diff -R help/ > foobar.patch but it looked nothing suitable for submitting.

If prefer them in unified format (-u), but except for that and a few wrong locations this looks pretty good.

3. How do you planed the reviewing process. Should i create a patch, submit this to you and you'll check it in the cvs repository?

Yepp.

Maybe it'll be better, that any editor has an cvs access.

We certainly can get you one, however I'd like to ensure a consistent typing and markup which is why I'm not too fond of this idea right now. The best way to get your CVS account soon is to flood my mailbox with high quality content so I get annoyed by applying your patches. :)

The reviewing process goes on text crosswise. Everyone is checkin the help from another editor?

This makes sense once there're more editors.

Thats it so far. Tell me if the introduction.xml is okey and i can go any further.

Looks good, keep going!

Roman Joost wrote:

2. How do i create a better patch? I tried:
cvs diff -R help/ > foobar.patch

but it looked nothing suitable for submitting.

All (or most) CVS operations are recursive by default. diff -u gives a unified diff, which is the preferred diff type for the GIMP in general, being quite readable. So

cvs diff -u help > help.patch

should do the trick.

To have this option on all the time, add the line "diff -u" to the file ~/.cvsrc (create the file if there isn't already one). You should probably consider adding the lines "update -dP" and "cvs -z3 -e/usr/bin/emacs" too.

That's the only one of your questions I have an answer for, though :)

Cheers,
Dave.

Am Son, 2003-07-27 um 19.18 schrieb Roman Joost:

okey.. i'll learn that i've to attache that damn file on the mail, when i mention it. .. brr

Not bad. A few points though:
- Easy writing style is fine
- We don't need a 1:1 translation; in case you can explain it better in German, do it.
- I'm not sure which article to use for GIMP in German so I normally don't write one. A male article sounds more strange than none at all but if we can find a good ruling -- all the better. - Watch stray English words (I found some ors', ands' and as') - Watch the formatting and indention, 2 spaces indention per tag instance and a line length of 80 characters maximum (I personally use 75 though which together with the indention keeps the maximum amount of characters per line between 50 and 70 thus helping reading because the eye can easier track the text, like columns in magazine)

I'll commit in a second, thanks a lot!

On Sunday 27 July 2003 3:13 pm, Daniel Egger wrote:

- I'm not sure which article to use for GIMP in German so I normally don't write one. A male article sounds more strange than none at all but if we can find a good ruling -- all the better.

In Portuguese, the current use is for a male article - and trying making it female would be pretty bizarre. As fa as I can recall, all computer prograns or aplications are refered as male here. But anyway, many words have their genders swapped between German and Portuguese anyway.

JS
->

Am Mon, 2003-07-28 um 17.47 schrieb Joao S. O. Bueno:

In Portuguese, the current use is for a male article - and trying making it female would be pretty bizarre. As fa as I can recall, all computer prograns or aplications are refered as male here. But anyway, many words have their genders swapped between German and Portuguese anyway.

I'm pretty confident that "die GIMP" (female) is wrong, it's either "der GIMP" (male) or "das GIMP" (no gender). I'd say it is "das GIMP" because the P stands for program which has no gender and for acronyms typically the last word determines the gender. However since no article is not a problem at all in most cases I'd rather go with this....

On 28 Jul 2003, Daniel Egger wrote:

Date: 28 Jul 2003 18:52:41 +0200
From: Daniel Egger
To: Joao S. O. Bueno
Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] writing german online help

Am Mon, 2003-07-28 um 17.47 schrieb Joao S. O. Bueno:

In Portuguese, the current use is for a male article - and trying making it female would be pretty bizarre. As fa as I can recall, all computer prograns or aplications are refered as male here. But anyway, many words have their genders swapped between German and Portuguese anyway.

I'm pretty confident that "die GIMP" (female) is wrong, it's either "der GIMP" (male) or "das GIMP" (no gender). I'd say it is "das GIMP" because the P stands for program which has no gender and for acronyms typically the last word determines the gender. However since no article is not a problem at all in most cases I'd rather go with this....

Foreign words generally use Das if i recall correctly.

Does German have a translation or share the word for the other type of Gimp?
:)

-- Alan

Hi,

sorry for catching up late on this thread. I failed to follow it while being mostly offline during camp preparation.

Roman Joost writes:

1. The German Umlauts are really annoying. Are there some pre-processors, which checks the umlauts and replaces them with an utf entity (or the predifined HTML umlauts... what else...)? If not, it think i'll write a little script. I forget them every time...

Why don't you simply write it all in UTF-8? Using HTML entities seems akward and error-prone. The helpbrowser plug-in is fully UTF-8 aware and if you use an editor that copes with UTF-8, you can simply use umlauts in your texts.

Sven

Hi,

On Tue, 2003-08-19 at 10:33, Roman Joost wrote:

Its written with UTF-8 Entities, so i think this thread is deprecated .. The only thing was a correct mapping of the umlauts. I setup my editor correctly and now i can write the docs without typing in the entities.

Excuse my ignorance, but what are UTF-8 entities? I had a look at the stuff in CVS:

Einführung
and I would have expected:

Einführung

(Let's hope the mail client transfers this correctly and marks the mail as UTF-8 encoded).

Sven

Hi,

On Tue, 2003-08-19 at 16:19, Roman Joost wrote:

AFAIK, you can't write german umlauts in xml files, which are utf-8 encoded.

Well, of course you can. That's the whole point of UTF-8 encoding. It provides a single encoding suitable for all languages so that they can coexist in the same file. All XML-1.0 compatible tools must handle UTF-8 correctly and there is thus no need to use entities.

Sven

Am Die, 2003-08-19 um 16.48 schrieb Sven Neumann:

Well, of course you can. That's the whole point of UTF-8 encoding. It provides a single encoding suitable for all languages so that they can coexist in the same file. All XML-1.0 compatible tools must handle UTF-8 correctly and there is thus no need to use entities.

There are two reasons not to use UTF-8 as input format: - There're still editors, consoles and other tools that have hefty troubles with UTF-8, especially when it's not used as the native encoding on the system
- Last time I looked most if not all processors have troubles transcoding UTF-8 to HTML entities or different charactersets, unfortunately quite a few browsers cannot properly display the former.

I'm sure we can switch really fast as soon as there is significant support or at least demand.

On Tue, Aug 19, 2003 at 08:59:45PM +0200, Daniel Egger wrote:

- Last time I looked most if not all processors have troubles transcoding UTF-8 to HTML entities or different charactersets,

Transcoding is a no-brainer, if that is a problem a simple one-liner can convert to whatever you want.

unfortunately quite a few browsers cannot properly display the former.

That's highly interesting. Even the venerable netscape-4 can properly display documents in utf-8, even utf-7.

I do a lot of work in this area, and widespread lack of utf-8 support is certainly unknown to me (and in any case, just convert to latin1 and you have universal support).

Am Mit, 2003-08-20 um 01.31 schrieb pcg@goof.com:

Transcoding is a no-brainer, if that is a problem a simple one-liner can convert to whatever you want.

I'm talking about the XSLT processors; sure a small perl/python/bash script will recode all generated HTML files in a directory, but as this does not seem necessary at the moment, I don't see a good reason to insert another step in the chain.

unfortunately quite a few browsers cannot properly display the former.

That's highly interesting. Even the venerable netscape-4 can properly display documents in utf-8, even utf-7.

The IEs had troubles until somewhen (haven't checked for quite some time). Also the smaller homegrown browsers did, probably also the old GIMP helpbrowser. And I'm not sure about lynx and w3c either. Usually one doesn't notice because ASCII is directly representable in the lower 7 bits UTF-8 and what more does a good American citizen need? :)

(and in any case, just convert to latin1 and you have universal support).

Guess what we're using right now... :)

I know UTF-8 is highly useful, but since it's just the flip of a switch and we don't really need it at the moment, it's causing more troubles than benefits. So I'd rather hold off with generating UTF-8 output for now.

Input is a completely different matter, but I think right now the technical barrier to writing documentation is already high enough to require the writers to have a UTF-8 compatible environment. Since the charset is choosable on a file-by-file base anyways I don't see any problem using this feature for languages that need it. :)

On Wed, Aug 20, 2003 at 03:52:09AM +0200, Daniel Egger wrote:

The IEs had troubles until somewhen (haven't checked for quite some time). Also the smaller homegrown browsers did, probably also the old GIMP helpbrowser. And I'm not sure about lynx and w3c either. Usually one doesn't notice because ASCII is directly representable in the lower 7 bits UTF-8 and what more does a good American citizen need? :)

FWIW, I just checked -- the latest version (as of Debian unstable) of lynx can handle the UTF-8 on my page correctly, w3m can't.

/* Steinar */

On Wed, Aug 20, 2003 at 03:52:09AM +0200, Daniel Egger wrote:

The IEs had troubles until somewhen (haven't checked for quite some

Are you sure? In my experience all of these problems stem from improper or missing charset declarations.

time). Also the smaller homegrown browsers did, probably also the old GIMP helpbrowser.

That might be true for some of them, but certainly isn't a major problem.

and we don't really need it at the moment, it's causing more troubles than benefits. So I'd rather hold off with generating UTF-8 output for

Well, there is currently no big problem with using e.g. latin1, so why not use it. The same is true for any japanese translations (if any emerge :): native encodings work fine mos of the time.

Since the charset is choosable on a file-by-file base anyways I don't see any problem using this feature for languages that need it. :)

The only problem is unwanted conversion (consider editors replacing tabs by changes and vice versa. That is a well-known problem that comes bakc in the form of automatic conversion by some editors).

So a policy of "use utf-8 for input" (as a goal!) makes sense, even when one can deviate from it on a per-file basis.

On Wed, Aug 20, 2003 at 12:38:23PM +0200, "Steinar H. Gunderson" wrote:

FWIW, I just checked -- the latest version (as of Debian unstable) of lynx can handle the UTF-8 on my page correctly, w3m can't.

Well, w3m can't handle html in most cases anyways, and there are far better alternatives to it, so I doubt anybody would still use w3m.

There is a line of what amount of brokenness we expect: mozilla can't handle e.g. html4 correctly, either, but that can usually be worked around with no problem at all. The same is probably true for netscape 4, lynx, ie and most other browsers. At some point (IMO: w3m) the amount of work needed to workaround is not worth the effort.