Hi,
I can't see how you translate in the MediaWiki scenario.

Julien

I propose to wholeheartly and open minded discuss alternatives. Please have a look into
http://lexaikon.dnsalias.org/~medius/mediawiki/index.php/Meta/Why_GIMP-Manual_as_wiki#Pro.27s_.26_Con.27s

and let me know what you think about it.

Axel,
your proposal is indeed original and tackles the problems from a whole different point of view.
By looking at the Blender documentation example I acknowledge that there are indeed a lot of advantages in the "wiki way" especially as far as authoring and proofreading is concerned.

As Julien pointed out I haven't properly got how a translator can actually translate a topic but from a user perspective I guess it would end up having something like Wikipedia where in the side bar you have "Other languages: English Deutsch ...". May be you coud add a sample page in your proof of concept wiki where you show how it looks when you make a topic available in more than one language?

Another big issue to think about is how to ship the manual in a packaged form to let users install an offline copy of it alongside the GIMP application. Is it possible? How do you think to solve this?

Other issues: What about the context sensitive help invocation mechanism? What's the impact on GIMP code?

Greets.

Axel Wernicke ha scritto:

Hi List,
...

I propose to wholeheartly and open minded discuss alternatives. Please have a look into
http://lexaikon.dnsalias.org/~medius/mediawiki/index.php/Meta/Why_GIMP-Manual_as_wiki#Pro.27s_.26_Con.27s
and let me know what you think about it.

Greetings, lexA

Alessandro Falappa ha scritto:

"Other languages: English Deutsch ...". May be you coud add a sample page in your proof of concept wiki where you show how it looks when you make a topic available in more than one language?

Nevermind I found it.

Cheers

Hi,

As Julien pointed out I haven't properly got how a translator can actually translate a topic

Phew! I'm not alone.
I still don't know how I can get
http://lexaikon.dnsalias.org/~medius/mediawiki/index.php/24_GIMPManual in french.

atb,

Julien

Hi,

On Wed, 2008-06-11 at 22:44 +0200, Axel Wernicke wrote:

Right now gimp calls the help by creating and opening an url that contains of some building blocks:

//

Example 'file://user/me/here/is/the/gimp-help/html' / 'en' / 'gimp-tool-rect-select' '.html'

That's not correct. GIMP, or rather the help plug-in, parses the gimp-help.xml file that is installed with the user manual for each language. It uses this index to translate from help IDs to URIs. If the respective URI is not available in the primary language, it tries to locate it in the list of fallback locales specified by the user. This defaults to 'en', in other words, the help ID is looked up in the english version of the user manual.

Sven

Hi,

As a newbie to this process, and having perused the previous procedures, I wholeheartedly endorse the move to a wiki-based editing process. If I had a machine that was up to it, I'd put in a sandbox, but I'm using a "quick, get me back in biz" laptop after a line surge fried my tower. I also think things can be done more intuitively and efficiently with a wiki. It still could be a managed membership-based entity. I think media-wiki is shepherded this way. I'll check the links later today.

Is there a current to-do list , or is that a myth I read about?

On Tuesday 10 June 2008, Axel Wernicke wrote:

Hi List,

due to the discussion in other threads on this list, I'd take the chance to propose one more idea on "how the editing of the GIMP manual could look".

What we achieved with the GIMP manual in the last couple of years is really astonishing to me. It's great how "just a bunch of enthusiasts" can create some thousand pages of documentation and even having fun with that. I'm really proud to be part of this! Despite all this success there is no doubt about the fact, that we are severe short of not only authors, but even more critical, interaction with our readers. Has anybody ever seen responses of reader on the list? Has ever a reader supported our work by bringing some enhancements or even tips for enhancements? If ever, this mus have been a verly long time ago unfortunately.

This is the base, I assume we all share, for the thinking on how to change that.

So, we kind of think to have found out what might cause the current situation:
- docbook editing is complicated

But is this all? May be we can find more reasons.

What did we come up so far with as a solution? - divide the crowd into authors and translators and hide the docbook xml (structures) as good as possible for the translators.

But ist that the only possible solution? May be we can simplify writing and in addition to that get rid of that programming taste that sticks to the "writing" of the GIMP Manual today?

I propose to wholeheartly and open minded discuss alternatives. Please have a look into
http://lexaikon.dnsalias.org/~medius/mediawiki/index.php/Meta/Why_G IMP-Manual_as_wiki#Pro.27s_.26_Con.27sand let me know what you think about it.

Greetings, lexA

YEs - a wiki approach would please a lot of people, but, just wikifying it might come to a too "loose" manual - we ? would not have the master language, and it would be very hard to synchronise changes.

But maybe we could get out with an "hybrid" system - for example, extracting the manual structure from the current XML files, and having more or less fixed topics on the wiki pages. Translators/users could then edit the text inside those topics, but not create new ones, change their order - that would be done in a master file (either in the wiki or in svn).

I can see how this would be achievable through scripts (I mean, to preserve the structure, and of course, populate whatever contents already written in the xml into the wiki). Some extra scripts could even make possible a wiki ->xml transform so we could have our multiple output version just as today.

Regards,

js ->

Hi,

On Thu, 2008-06-12 at 07:57 +0200, Axel Wernicke wrote:

Thanks for pointing that out. I should have known this. I assume it would be possible to adapt the help plug-in to a wiki based scenario. May be users with a stable online connection could even be routed to the online version of the wiki prior to the offline files and avoid the "hassle" of downloading the whole gimp-help package.

That is entirely unrelated to a move to a wiki. In fact I am currently preparing the help plug-ins in GIMP for online use of the user manual. Most of the code is already in trunk. Some final changes are missing, but when they are done, the user will be able to choose between using a locally installed copy of the user manual or accessing the online version directly.

Sven

Hi,

GIMP UI strings are in gnome: 66 different .po. Each of them is often updated.
It would be a real pity for the GIMP spreading to do without these 66 experimented translators.
IMO, gimp-help must join the GNOME team. The gettext scenario is necessary.

The Wiki scenario will bring a lot of text editions. We can imagine that languages versions progressively will become independant from each others. Valuable things can be introduced in a language I can't understand. The unity of the gimp-help project will be broken. Is it easy to find what has changed in the Wiki?

atb,

Julien

On Thu, Jun 12, 2008 at 03:39:33PM +0200, julien wrote:

Hi,

GIMP UI strings are in gnome: 66 different .po. Each of them is often updated.
It would be a real pity for the GIMP spreading to do without these 66 experimented translators.
IMO, gimp-help must join the GNOME team. The gettext scenario is necessary.

The Wiki scenario will bring a lot of text editions. We can imagine that languages versions progressively will become independant from each others. Valuable things can be introduced in a language I can't understand. The unity of the gimp-help project will be broken. Is it easy to find what has changed in the Wiki?

So, Joan, Julien and me are all convicted that a wikipedia approach it not without (big) drawbacks.

The use of the gettext tool with all the .po/.pot file format conversion is meant mainly to enable:

- automatic revision control: easily find(!!) and update(!) updated strings - use of specialist translation editors (poedit/kbabel/gtranslator/emacs/etc.) - even tools with web interface ready like rosetta (wich enable group revision and commit supervision...) or pottle: see -> http://translate.sourceforge.net/wiki/

this is _much_ more than wiki!

Hi,

On Thu, 2008-06-12 at 22:30 +0200, Axel Wernicke wrote:

I don't see how the UI sting .po files are connected to the gimp- help(.po) files. The UI strings are embedded in text in the gimp- help.po, so no automatic detection or translation derived from the UI .po files - right?

Not quite. There are tools that build a translation database from the po files you feed it. You can build a database that has all translated UI strings from GIMP, or even the whole GNOME project. This database will then be used in your favorite po file editor to suggest translations. This makes translations more consistent.

so, these translators are expected to do not only some dozens of strings, but a couple hundred pages of text and images in the future? Do they know that already?

They are already doing that for a lot of user manuals. Look at http://l10n.gnome.org/module/gnome-user-docs for example.

Sven

Hi Axel

GIMP UI strings are in gnome: 66 different .po. Each of them is often updated.

I don't see how the UI sting .po files are connected to the gimp-help(.po) files. The UI strings are embedded in text in the gimp-help.po, so no automatic detection or translation derived from the UI .po files - right?

What that? I only mean that if gimp-help joins the gnome team, it will be translated to 66 languages.

It would be a real pity for the GIMP spreading to do without these 66 experimented translators.

so, these translators are expected to do not only some dozens of strings, but a couple hundred pages of text and images in the future? Do they know that already?

At least in the 'fr' gnome, there are a section for UI and a section for docs. In the doc section, there are a lot of translated docs...

Greetings,

Julien

Hi all :-)
This looks to me to be a discussion among programmers or people thinking in the programmers way.
Why not relax and start thinking from scratch, independent of what programs and editors etc. are valuable? When starting a project I usually put together a list something like this: 1. What do we need?
a. A database (DB) or similar containing all files necessary to build the help files. One DB for every language or one containing them all. b. A program for editing the files in the DB. (On my home computer, not directly on the DB).
c. A program to automatically build the necessary html/dbf files for the end user every time the contents in the DB is changed for a particular language (if the DB files are in another format than html). 2. What do we have?
a. A DB containing the actual files in xml format. Every language in each file.
b. Programs to automatically build the html and dbf files for each language.
c. Some more or less usefully editors. 3. What do I wish?
a. An editor showing the original language together with my language. Also the possibility to read other languages at the same time at my own choose.
b. I should be able to set the editor to show one line, one paragraph or the whole page in each chosen language at will. c. All or most of the necessary codes (tags) generated by the editor. I only have to write the plain text. d. If I'm an author, I also am able to write new original text or change it.
e. All up- and downloads to/from the DB is done automatically when I chose to do so.
f. The whole system should be OS independent. 4. Find programs to fulfill my wishes. (This is of course a very coarse listing, lots of details would be added if in real use).

According to this list it seems that the greatest problem at the moment is the lack of an editor

This discussions remind me of the start of the computer era: We have invented a fantastic machine, what do we use it for? Well, I'm not a programmer, only a user. (Although I have written some short programs in different languages when needed to). The threshold for becoming a writer/author is at the moment too high. The golden question is how to lower this threshold? I used unnecessary amount of time to learn how to do this and that before I even was able to do what I want to do: translate. (Thanks to you all and especially Julien for leading me step by step on the road to understanding).

Perhaps I am out in the wilderness? Perhaps I have misunderstood the whole discussion? Perhaps the list is completed without my notice? Perhaps I should not sent this mail? Perhaps ... Kolbj?rn

Hi Kolbjorn, and others,

I like Kolbjorn's comments. I think what is at issue is the DB he mentions, and the desire to protect the document and the harmony of the translations, while not inhibiting the writers and translators or forcing them to think as "programmers". I agree an editing team and/or a mechanism which distinguishes between working and release versions would be helpful. The capacity of the hosting provider(s) may also be at issue. The current discussion seeks to solve previous problems, so we can return to writing and not mess it up. - Morley

On Sun, Jun 15, 2008 at 3:58 PM, Kolbj?rn Stuest?l wrote:

Hi all :-)
This looks to me to be a discussion among programmers or people thinking in the programmers way.
Why not relax and start thinking from scratch, independent of what programs and editors etc. are valuable? When starting a project I usually put together a list something like this: 1. What do we need?
a. A database (DB) or similar containing all files necessary to build the help files. One DB for every language or one containing them all. b. A program for editing the files in the DB. (On my home computer, not directly on the DB).
c. A program to automatically build the necessary html/dbf files for the end user every time the contents in the DB is changed for a particular language (if the DB files are in another format than html). 2. What do we have?
a. A DB containing the actual files in xml format. Every language in each file.
b. Programs to automatically build the html and dbf files for each language.
c. Some more or less usefully editors. 3. What do I wish?
a. An editor showing the original language together with my language. Also the possibility to read other languages at the same time at my own choose.
b. I should be able to set the editor to show one line, one paragraph or the whole page in each chosen language at will. c. All or most of the necessary codes (tags) generated by the editor. I only have to write the plain text. d. If I'm an author, I also am able to write new original text or change it.
e. All up- and downloads to/from the DB is done automatically when I chose to do so.
f. The whole system should be OS independent. 4. Find programs to fulfill my wishes. (This is of course a very coarse listing, lots of details would be added if in real use).

According to this list it seems that the greatest problem at the moment is the lack of an editor

This discussions remind me of the start of the computer era: We have invented a fantastic machine, what do we use it for? Well, I'm not a programmer, only a user. (Although I have written some short programs in different languages when needed to). The threshold for becoming a writer/author is at the moment too high. The golden question is how to lower this threshold? I used unnecessary amount of time to learn how to do this and that before I even was able to do what I want to do: translate. (Thanks to you all and especially Julien for leading me step by step on the road to understanding).

Perhaps I am out in the wilderness? Perhaps I have misunderstood the whole discussion? Perhaps the list is completed without my notice? Perhaps I should not sent this mail? Perhaps ... Kolbj?rn

On Sunday 15 June 2008, Kolbj?rn Stuest?l wrote:

Perhaps I am out in the wilderness? Perhaps I have misunderstood the whole discussion? Perhaps the list is completed without my notice? Perhaps I should not sent this mail? Perhaps ... Kolbj?rn

No ...you sumarized the problems in a nice way - and had put in plain English what I (and maybe otehrs) had espressed ony partially. I don? know however if roman is already doing some other thing.

Regards,

js ->

On Thu, Jun 12, 2008 at 10:39 PM, julien wrote:

Is it easy to find what has changed in the Wiki?

This is the most problem of wiki. if just few languages or pages, it's not a matter. but we have 12 languages and a thousond pages.. I can't imagine how to find changes of each pages

On Mon, Jun 16, 2008 at 12:32:25PM +0900, Choi, JiHui wrote:

On Thu, Jun 12, 2008 at 10:39 PM, julien wrote:

Is it easy to find what has changed in the Wiki?

This is the most problem of wiki. if just few languages or pages, it's not a matter. but we have 12 languages and a thousond pages.. I can't imagine how to find changes of each pages

Yes it could be a nightmare without some automated tools!

:-(

This is THE reason of gettext. I do not know of anything similar of gettext with the fuzzy/untranslated automatic detection (if there is something outthere, please tell me more!).
If it could be implemented in a wiki engine, than wiki could be the perfet solution: easy and manageable.
Now is only easy (at the start) but not manageable.

On Sun, Jun 15, 2008 at 11:58:56PM +0200, Kolbj?rn Stuest?l wrote:

Hi all :-)
This looks to me to be a discussion among programmers or people thinking in the programmers way.
Why not relax and start thinking from scratch, independent of what programs and editors etc. are valuable? When starting a project I usually put together a list something like this: 1. What do we need?
a. A database (DB) or similar containing all files necessary to build the help files. One DB for every language or one containing them all.

ok

b. A program for editing the files in the DB. (On my home computer, not directly on the DB).

could be done via web or using a disconnected editor/tool.

c. A program to automatically build the necessary html/dbf files for the end user every time the contents in the DB is changed for a particular language (if the DB files are in another format than html).

yes

Missing:

d. a program that see for changes in the structure/reference language and report it in all the languages affected to easy the revision control.

2. What do we have?
a. A DB containing the actual files in xml format. Every language in each file.

ok

b. Programs to automatically build the html and dbf files for each language.

ok

c. Some more or less usefully editors.

ok

3. What do I wish?
a. An editor showing the original language together with my language.

ok

Also the possibility to read other languages at the same time at my own choose.

not necessary/so important. You can always compare the different language results in html.

b. I should be able to set the editor to show one line, one paragraph or the whole page in each chosen language at will.

one line not necessary.

c. All or most of the necessary codes (tags) generated by the editor. I only have to write the plain text.

yes but only for those willing to contribute without necessary skills. This could be desiderable but not really necessary. The web interface is IMHO the easiest method to do this.

d. If I'm an author, I also am able to write new original text or change it.

IMHO there are different types of authors with different tasks (but one single person could be all the types at once...): 1) manual structure author
2) reference language author
3) local translation author

e. All up- and downloads to/from the DB is done automatically when I chose to do so.

transtlated: checkout/commit from/to svn

f. The whole system should be OS independent.

through the web interface is easy accomplished but for the whole system is difficoult to implement in a non linux environment...

g. the system should check automatically for updated/added/removed paragraphs with list of ALL changes that affect ALL languages (the sole tool that is able to manage this is the gettext tools/utils like msgmrg, see for example intltool-update in the gnome environment)

4. Find programs to fulfill my wishes. (This is of course a very coarse listing, lots of details would be added if in real use).

done

According to this list it seems that the greatest problem at the moment is the lack of an editor

mmmm no IMHO the lack of an AUTOMATIC revision control.

This discussions remind me of the start of the computer era: We have invented a fantastic machine, what do we use it for? Well, I'm not a programmer, only a user. (Although I have written some short programs in different languages when needed to). The threshold for becoming a writer/author is at the moment too high.

I understand and agree.

The golden question
is how to lower this threshold? I used unnecessary amount of time to learn how to do this and that before I even was able to do what I want to do: translate. (Thanks to you all and especially Julien for leading me step by step on the road to understanding).

Perhaps the web/wiki way is the easiest way...

Perhaps I am out in the wilderness? Perhaps I have misunderstood the whole discussion? Perhaps the list is completed without my notice? Perhaps I should not sent this mail? Perhaps ... Kolbj?rn

Thank you very much for this email!

bye

I haven't read the threads, so apologies if i'm repeating something: why not let the pages in each language develop independently of each other and the english version (assuming the wiki model goes ahead)? With wikipedia at present, languages on different pages are being developed totally independently to each other and that seems to be working fine.

--- On Mon, 6/16/08, Marco Ciampa wrote:

From: Marco Ciampa
Subject: Re: [Gimp-docs] GIMP manual writing in 2009 To: gimp-docs at lists.XCF.Berkeley.EDU Date: Monday, June 16, 2008, 8:14 PM On Mon, Jun 16, 2008 at 12:32:25PM +0900, Choi, JiHui wrote:

On Thu, Jun 12, 2008 at 10:39 PM, julien

wrote:

Is it easy to find what has changed in the Wiki?

This is the most problem of wiki. if just few languages or pages, it's not a matter. but we have 12 languages and a thousond pages.. I can't imagine how to find changes of each pages

Yes it could be a nightmare without some automated tools!

:-(

This is THE reason of gettext. I do not know of anything similar of gettext
with the fuzzy/untranslated automatic detection (if there is something
outthere, please tell me more!).
If it could be implemented in a wiki engine, than wiki could be the perfet
solution: easy and manageable.
Now is only easy (at the start) but not manageable.

On Mon, Jun 16, 2008 at 06:33:44AM -0700, Charlie Albright wrote:

I haven't read the threads, so apologies if i'm repeating something: why not let the pages in each language develop independently of each other and the english version (assuming the wiki model goes ahead)? With wikipedia at present, languages on different pages are being developed totally independently to each other and that seems to be working fine.

Mainly for two reasons (that are just the same reasons for which it is handy to have just one reference language):

1) the contestual help system: the f1 key should go to the same section of the local language. The manual structure must be near the same for all the lanuage for this mechanism to work. I cannot think about a new reference without affecting all the other languages.

2) the manual structure: creating and mantaining coherent the structure of a manual with glossary, index, tutorial and references is a tough work! Many of us are simply translators and would simply remain so, contributing only in those fields where they are better suited. I really appreciate the work done by the manual administrators, I could not do any better!

ciao!

Hi,

On Mon, 2008-06-16 at 16:28 +0200, Marco Ciampa wrote:

1) the contestual help system: the f1 key should go to the same section of the local language. The manual structure must be near the same for all the lanuage for this mechanism to work. I cannot think about a new reference without affecting all the other languages.

There's a mapping from help ID to HTML page/anchor for each language. So for the context help to work, there is no need for the same structure to be used for all languages. Nevertheless I would suggest that you stick to a common structure for other reasons.

Sven