-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi all,

Am 25.05.2006 um 08:00 schrieb julien:

We are now many translators working on the Gimp help. Often, we work on the same files. When updating, this generates conflicts and warnings: fixing them is a waste of time. We must respect some discipline in selecting the files we want work on.
On http://wiki.gimp.org/GimpDocsWip we can indicate which files we are working on. Please use it.

I 100% agree with you. ( The wiki page is at http://wiki.gimp.org/ gimp/GimpDocsWip )

greetings, lexA

Julien

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi all,

to enhance the fields of potential collisions I've put the names of the authors and the chapter into a table at the wiki. Feel free to add yourself and keep information up to date. Please put the date of the update always into the table.

greetings, lexa

Am 25.05.2006 um 08:06 schrieb Axel Wernicke:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi all,

Am 25.05.2006 um 08:00 schrieb julien:

We are now many translators working on the Gimp help. Often, we work on the same files. When updating, this generates conflicts and warnings: fixing them is a waste of time. We must respect some discipline in selecting the files we want work on.
On http://wiki.gimp.org/GimpDocsWip we can indicate which files we are working on. Please use it.

I 100% agree with you. ( The wiki page is at http://wiki.gimp.org/ gimp/GimpDocsWip )

greetings, lexA

Julien

Dne ?tvrtek 25 kv?ten 2006 08:00 julien napsal(a):

We are now many translators working on the Gimp help. Often, we work on the same files. When updating, this generates conflicts and warnings: fixing them is a waste of time.
We must respect some discipline in selecting the files we want work on. On http://wiki.gimp.org/GimpDocsWip we can indicate which files we are working on. Please use it.

The link doesnt work foer me.
Shouldnt we separate the files by language to remove the problem? Many edits i make are edits like improving the style, removing typos, fixing terminology - these tend to affect many files (and it is often not predictable which files until actually doing the work - i use grep extensivelly)

Jakub Friedl

On Thu, May 25, 2006 at 08:35:21AM +0200, Axel Wernicke wrote:

Hi all,

to enhance the fields of potential collisions I've put the names of the authors and the chapter into a table at the wiki. Feel free to add yourself and keep information up to date. Please put the date of the update always into the table.

greetings, lexa

Great idea! An evident drawback: what if there is more than one people working on the same section or people working on more or all sections together? Who wins?

On the page

http://wiki.gimp.org/gimp/GimpDocsWip

I've put "Done" on the toolbox section of the italian translation. Is it correct? It can be useful as a trace to see what has to be done to complete the translation.

bye

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi Jakub,

Am 25.05.2006 um 10:44 schrieb Jakub Friedl:

The link doesnt work foer me.

I mailed the correct one to the list already.

Shouldnt we separate the files by language to remove the problem?

This way I think we would lose the one GIMP manual. We instead would have a dozen books that more and more will diverse or even die. Be sure I know many of the multi-language annoyances in our files, but anyway I think they are the only way to get ONE manual in different languages. This stays true as long as we work on a day by day basis on the (en) manual, not having a strong focus on en an timing. To change that would mean we'd need a schedule with fixed(!) deadlines. "Somebody" would write and finish (!) the en book and then all the "ohters" would take that bible and translate it into their respective language. - AFAIK is this not the style of work that fits our needs and pleasures.

Many edits i make are edits like improving the style, removing typos, fixing
terminology - these tend to affect many files (and it is often not predictable which files until actually doing the work - i use grep extensivelly)

This is a fact I'm experiencing too. May be we should (as we do already today) limit these changes to the absolutely necessary and collect ideas for huge grep jobs (Gimp -> GIMP would be one of my favorites btw. ) and do them after an anouncement on the list. This way everybody would have a chance to check in local changes in the first hand.

After all it's true: commit early, commit often :)

greetings, lexa

Jakub Friedl

On Thu, May 25, 2006 at 10:44:23AM +0200, Jakub Friedl wrote:

Dne ?tvrtek 25 kv?ten 2006 08:00 julien napsal(a):

We are now many translators working on the Gimp help. Often, we work on the same files. When updating, this generates conflicts and warnings: fixing them is a waste of time.
We must respect some discipline in selecting the files we want work on. On http://wiki.gimp.org/GimpDocsWip we can indicate which files we are working on. Please use it.

The link doesnt work foer me.
Shouldnt we separate the files by language to remove the problem? Many edits i make are edits like improving the style, removing typos, fixing terminology - these tend to affect many files (and it is often not predictable which files until actually doing the work - i use grep extensivelly)

Dear Jakub, you are correct but we need a pragmatic approach!

If I have understood well the intent of the page creators, that page is a sort of semaphore to avoid some conflicts (not all). I think that that page doesn't (and it shouldn't) reflect the small fixies that are easily resolved if they are really small...
The page is meant for telling to all us: " ... I'm doing a massive chenge here. Please do not do the same on the same area until I've committed it all, then go..."

On Thu, May 25, 2006 at 11:11:35AM +0200, Axel Wernicke wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi Jakub,

Am 25.05.2006 um 10:44 schrieb Jakub Friedl:

The link doesnt work foer me.

I mailed the correct one to the list already.

Shouldnt we separate the files by language to remove the problem?

This way I think we would lose the one GIMP manual. We instead would have a dozen books that more and more will diverse or even die. Be sure I know many of the multi-language annoyances in our files, but anyway I think they are the only way to get ONE manual in different languages. This stays true as long as we work on a day by day basis on the (en) manual, not having a strong focus on en an timing. To change that would mean we'd need a schedule with fixed(!) deadlines. "Somebody" would write and finish (!) the en book and then all the "ohters" would take that bible and translate it into their respective language. - AFAIK is this not the style of work that fits our needs and pleasures.

100% agree.

Many edits i make are edits like improving the style, removing typos, fixing
terminology - these tend to affect many files (and it is often not predictable which files until actually doing the work - i use grep extensivelly)

This is a fact I'm experiencing too. May be we should (as we do already today) limit these changes to the absolutely necessary and collect ideas for huge grep jobs (Gimp -> GIMP would be one of my favorites btw. )

100% agree: lets kill it!

and do them after an anouncement on the list. This way everybody would have a chance to check in local changes in the first hand.

After all it's true: commit early, commit often :)

Oh yeah!!! ;-)

bye

This way I think we would lose the one GIMP manual. We instead would have a dozen books that more and more will diverse or even die. Be sure I know many of the multi-language annoyances in our files, but anyway I think they are the only way to get ONE manual in different languages. This stays true as long as we work on a day by day basis on the (en) manual, not having a strong focus on en an timing. To change that would mean we'd need a schedule with fixed(!) deadlines. "Somebody" would write and finish (!) the en book and then all the "ohters" would take that bible and translate it into their respective language. - AFAIK is this not the style of work that fits our needs and pleasures.

I do not agree. There is no need to keep all the manuals same (and it is not the case now, anyway). What we need is to keep the same basic structure, which is basically defined by help IDs. No need to have identical books.

I actually thought that there was already a consensus to split the files and it wasnt done yet because of technical reasons.

Keeping all languages in same files is not the way to go. It will become PITA once some languages start lagging behind - restructuring chapters, for example, while there is noone available to do it for some of the languages, would be a problem.

Please, lets split them

Jakub Friedl

On Thu, May 25, 2006 at 11:35:53AM +0200, Jakub Friedl wrote:

This way I think we would lose the one GIMP manual. We instead would have a dozen books that more and more will diverse or even die. Be sure I know many of the multi-language annoyances in our files, but anyway I think they are the only way to get ONE manual in different languages. This stays true as long as we work on a day by day basis on the (en) manual, not having a strong focus on en an timing. To change that would mean we'd need a schedule with fixed(!) deadlines. "Somebody" would write and finish (!) the en book and then all the "ohters" would take that bible and translate it into their respective language. - AFAIK is this not the style of work that fits our needs and pleasures.

I do not agree. There is no need to keep all the manuals same (and it is not the case now, anyway). What we need is to keep the same basic structure, which is basically defined by help IDs. No need to have identical books.

But it's _MUCH_ simpler!!!

I actually thought that there was already a consensus to split the files and it wasnt done yet because of technical reasons.

Definitely it is not the only reason...

Keeping all languages in same files is not the way to go. It will become PITA once some languages start lagging behind - restructuring chapters, for example, while there is noone available to do it for some of the languages, would be a problem.

There is no solution about the translators missing, whichever method you consider and there is no validation problems not solvable by a good old ;-)

Please, lets split them

Please don't!
Translating is one thing, restructuring the manual, another.

What if some languages different from english take different directions? It _must_ be a _master_ language (english) to make all the other teams in the condition of being able to only translate and not to recreate another manual (still with the same IDs).
I know that this is more an organizative problem, not really technical but I do not consider it a good idea if it means to produce different versions of the manual, one per language. The python scripts are already there and working (well) to do the job but, before the split we should consider seriously the organizative problem. It definitely should never happen to have some, say german or chinese content, not present in the english manual that the majority of all it is not able to uderstand and translate in the mother tongue.

I'll agree at this "logical" decision only after someone assuring me about a "master" english version as a template for all the others an with the help and collaboration of all of us to make it "one and complete".

bye

On Thu, 25 May 2006, Jakub Friedl wrote:

This way I think we would lose the one GIMP manual. We instead would have a dozen books that more and more will diverse or even die. Be sure I know many of the multi-language annoyances in our files, but anyway I think they are the only way to get ONE manual in different languages. This stays true as long as we work on a day by day basis on the (en) manual, not having a strong focus on en an timing. To change that would mean we'd need a schedule with fixed(!) deadlines. "Somebody" would write and finish (!) the en book and then all the "ohters" would take that bible and translate it into their respective language. - AFAIK is this not the style of work that fits our needs and pleasures.

I do not agree. There is no need to keep all the manuals same (and it is not the case now, anyway). What we need is to keep the same basic structure, which is basically defined by help IDs. No need to have identical books.

Hmmm, I have strong feeling of disagreement with you:

The `one story per file, select your preferred language' is a good way to preserve the style of the manual over all languages; although the sentences can be rearanged in several ways, this limits the amount with which a paragraph can drift from its original meaning. Why would we want differences in explanation when we try to explain about the same programme???

I actually thought that there was already a consensus to split the files and it wasnt done yet because of technical reasons.

I would even prefer it if there were a way to put different language versions into the same PNG-files; `When compiling the book; select the appropriate language, if its not available select the default instead': we are working on the `source code': The HTML, pdf, etc ARE indeed split up according to language.

Keeping all languages in same files is not the way to go. It will become PITA once some languages start lagging behind - restructuring chapters, for example, while there is noone available to do it for some of the languages, would be a problem.

Some languages are already lagging behind (e.g. NL) and it might look like an amputation when chapters are restructured, but problematic sections can easily be excluded, or moved to a `old, but not obsolete' part of the file; If one takes the effort of restructuring a chapter, I suppose he or she should also take the effort to add some explanatory comments for other contributors?

But of course these are my feelings and discussion is a a good way to combine visions and improve the ultimate result...

BTW: Mea Culpa about the Gimp thing, something to do with the LaTeX mores of: {\sc Gimp} where the last three letters are small capitals ({\sc gimp}, would be even more consistent), which differ from regular capitals. According to this philosophy I even prefer gimp above GIMP. Likewise, when Axel or Roman explained me about it, I prefer the possibility of systematising quotes: Text instead of `text', "text", 'text' or other permutations.

Greetings

But it's _MUCH_ simpler!!!

i do not think so. i work at many different manuals, but no one is done in this way

Please don't!
Translating is one thing, restructuring the manual, another.

there is no need for word by word translation. sometimes non english content is ahead of english. sometimes english is not as good as it can be - yes content from other languages should be translated into english then, but i do not expect it to happen always

What if some languages different from english take different directions?

what is problem with it? as long as it results in a functional, usable, good manual, there is no problem with it

I know that this is more an organizative problem, not really technical but I do not consider it a good idea if it means to produce different versions of the manual, one per language. The python scripts are already there and working (well) to do the job but, before the split we should consider seriously the organizative problem. It definitely should never happen to have some, say german or chinese content, not present in the english manual

it will happen (and it already happened) unless you enforce strict translation of the english content policy. i do not agree with that (and i wouldnt enjoy working like that, that would mean that all my future contributions will be english and czech version will be dead - until new translator is found)

Jakub Friedl wrote:

But it's _MUCH_ simpler!!!

i do not think so. i work at many different manuals, but no one is done in this way

What if some languages different from english take different directions?

what is problem with it? as long as it results in a functional, usable, good manual, there is no problem with it

The problem is that users from different countries meet online. Usually, the language they use to communicate will be English - more or less correct, that is. Both of them might know enough of it to understand their respective problems, but if someone want to reference the manual in the other's native language, there will be a problem. You can't tell someone "read part one chapter 5 section 4", because this will not necessarily be the same in two different languages.

IMO, you can't reach two of your goals - functional and usable - this way, though the individual manual might still be good for their respective readers.

it will happen (and it already happened) unless you enforce strict translation of the english content policy. i do not agree with that (and i wouldnt enjoy working like that, that would mean that all my future contributions will be english and czech version will be dead - until new translator is found)

A "translation table" would be nice - cross-referencing the same content in different languages (see also bug http://bugzilla.gnome.org/show_bug.cgi?id=168256)

Just my 2 cents, Michael

Dear Jakub,

But it's _MUCH_ simpler!!!

i do not think so. i work at many different manuals, but no one is done in this way

And...? If all that the majority of people do was right I were using Windows instead of Linux now... :-)

Please don't!
Translating is one thing, restructuring the manual, another.

there is no need for word by word translation. sometimes non english content is ahead of english.

ok I believe you since I'll never know. I cannot understand Czech so all the work done in that language for my language is lost...and _this_ is really bad.

sometimes english is not as good as it can be - yes content from other languages should be translated into english then, but i do not expect it to happen always

If it does not happen always it will happen sometimes... The effort multiplied for the number of other languages that that effort could affect and the benefits related outweight the missing chapters... If I write a little thing but that chapter is then translated in, say, seven different languages, what an improvement!

What if some languages different from english take different directions?

what is problem with it? as long as it results in a functional, usable, good manual, there is no problem with it

the loss of a cross reference is a great loss...think about it... And consider that the more people are affected by a central template the more are those people involved in improving it and the better it became for all of us...
The power of development is stricted related to the size and cohesion of the team. More indipendents teams that _do not_ work on the same project, the more weak the common project is...
National teams are a resource for all of us if they can work toghether...

I know that this is more an organizative problem, not really technical but I do not consider it a good idea if it means to produce different versions of the manual, one per language. The python scripts are already there and working (well) to do the job but, before the split we should consider seriously the organizative problem. It definitely should never happen to have some, say german or chinese content, not present in the english manual

it will happen (and it already happened) unless you enforce strict translation of the english content policy.

I see that many 'deviations' are going to be less then in the past, the more languages are coming in...
It is like with Linux: the more distros are outthere, the more important become to have a commong ground and more standardizations efforts are being born...

i do not agree with that (and i wouldnt enjoy working like that, that would mean that all my future contributions will be english and czech version will be dead - until new translator is found)

sound like a promise? :-) noone is asking you to write in english. Just, when you find some interesting things written in Czech, that are missing try to translate those contents in english too, please! Your effort will be very very appreciated by all the comunity at large, thanks!

sound like a promise? :-) noone is asking you to write in english. Just,

i have already contributed english content, so no promises needed

On Tue, May 30, 2006 at 12:05:49PM +0200, Jakub Friedl wrote:

sound like a promise? :-) noone is asking you to write in english. Just,

i have already contributed english content, so no promises needed

It is difficult to transmit humor by email but this part of the message was full of it. Seen the :-) smile?

Please do not take me too seriously...