I'm working on a few minor translations to get started. A couple of questions:
"Nom d'outil ou partie" I'm translating to "name of utility or function" - is "function" appropriate? I'm not sure what the comment signifies exactly, so need some help.
The English version of the xml file is not really a translation of the French, as there is a lot of extra stuff in the English (for example, in the "SVG Goals" section). Should I attempt to reconcile the differences and cut everything extra out of the English version (most of it is not really useful, in my opinion), or is the extra stuff in the English version getting put into the French version eventually.
Sorry if I'm a bit confused by this. I really want to get my hands dirty, but keep coming upon roadblocks :)
JF
can someone stick this in images/sshot.en for me please?
Joshua Facemyer / Impressus Art a écrit :
I'm working on a few minor translations to get started. A couple of questions:
"Nom d'outil ou partie" I'm translating to "name of utility or function"
- is "function" appropriate? I'm not sure what the comment signifies
exactly, so need some help.
"tool name or section name" should be better IMO. If i remember this is commented, just for doc-writer.
The English version of the xml file is not really a translation of the French, as there is a lot of extra stuff in the English (for example, in the "SVG Goals" section). Should I attempt to reconcile the differences and cut everything extra out of the English version (most of it is not really useful, in my opinion), or is the extra stuff in the English version getting put into the French version eventually.
In many cases, english files have been done before, especially does taken from release ntoes. Thoses, should be kept complete if they are understandable.
IMO, french and english don't really have to be exactly the same, nor a german... We can imagine that translation also need some "local culture translation" that would sometimes need more or less info on a subject or different kind of approach. of course, the nearer the translation will be, the easier we will maintain it.
I hope it helps.
Cedric
btw : yur picture is added in the repository
For the Section IDs, sometimes (in EN) they reflect the command/tool name directly (Such as "save") and sometimes they're a verbal description ("saving"). Does it matter which I use? I'll try to make them all the same, but need to know which is preferred.
Speaking of which, is there a documentation conventions doc somewhere?
JF
On 10/10/07, Joshua Facemyer / Impressus Art wrote:
For the Section IDs, sometimes (in EN) they reflect the command/tool name directly (Such as "save") and sometimes they're a verbal description ("saving"). Does it matter which I use? I'll try to make them all the same, but need to know which is preferred.
Speaking of which, is there a documentation conventions doc somewhere?
That's a good point, we need conventions. I suggest copying title in ID.
Alexandre
I made no convention as long i've done it alone, sometimes quite quickly and the best i could (especially at the beginning where i even didn't know docbook and other stuffs).
usually, i tryed to follow tool or command name but there are sometimes sub-section not realted to some UI object.
I see no trouble in doing a convention. I don't know if there is already one in gnome-doc project, but may be somethings like gnome icon naming project (or tango which is the same now i guess) could be a basis.
"
Icon Naming Guidelines
Here we define some guidelines for when creating new icons that extend the standardized list of icon names defined here, in order to provide icons for more specific MIME types, devices, or international flags.
*
Icon names are in the en_US.US_ASCII locale. This means that the allowable characters in the icon names, must fall withing the US-ASCII character set. As a further restriction, all icon names may only contain lowercase letters, numbers, underscore, dash, or period characters. Spaces, colons, slashes, and backslashes are not allowed. Also, icon names must be spelled as they are in the en_US dictionary.
*
The dash “-” character is used to separate levels of specificity in icon names, for all contexts other than MimeTypes. For instance, we use “input-mouse” as the generic item for all mouse devices, and we use “input-mouse-usb” for a USB mouse device. However, if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic icon from the current theme is preferred, in order to keep consistent style.
*
Icons for branded applications should be named the same as the binary executable for the application."
for ex :
document-new
edit-find
object-flip-vertical
we could at the same time do it for section ID but also for pictures. our trouble is were we wish to have several picture in a section : should we add a number or "--extrascomment"
Any opinion ?
Le Tuesday 09 October 2007 23:37:53 radar.map35@...6..., vous avez écrit :
I made no convention as long i've done it alone, sometimes quite quickly and the best i could (especially at the beginning where i even didn't know docbook and other stuffs).
usually, i tryed to follow tool or command name but there are sometimes sub-section not realted to some UI object.
I see no trouble in doing a convention. I don't know if there is already one in gnome-doc project, but may be somethings like gnome icon naming project (or tango which is the same now i guess) could be a basis.
"
Icon Naming GuidelinesHere we define some guidelines for when creating new icons that extend the standardized list of icon names defined here, in order to provide icons for more specific MIME types, devices, or international flags.
* Icon names are in the en_US.US_ASCII locale. This means that the allowable characters in the icon names, must fall withing the US-ASCII character set. As a further restriction, all icon names may only contain lowercase letters, numbers, underscore, dash, or period characters. Spaces, colons, slashes, and backslashes are not allowed. Also, icon names must be spelled as they are in the en_US dictionary. * The dash “-” character is used to separate levels of specificity in icon names, for all contexts other than MimeTypes. For instance, we use “input-mouse” as the generic item for all mouse devices, and we use “input-mouse-usb” for a USB mouse device. However, if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic icon from the current theme is preferred, in order to keep consistent style. * Icons for branded applications should be named the same as the binary executable for the application."for ex :
document-new
edit-find
object-flip-vertical
we could at the same time do it for section ID but also for pictures. our trouble is were we wish to have several picture in a section : should we add a number or "--extrascomment"
Any opinion ?
in french : Si on veut insérer une nouvelle image lors d'une nouvelle fonctionnalité, il faudra modifier tous les chiffres...ça risque d'être pénible. --extracomment me paraît une meilleure solution, plus facile pour maintenir un manuel toujours d'acutalité.
in english : "--extracomment" is more easier to maintain.
Resum : i vote --extracomment.
Elisa who have to learn speak english.
Le Tuesday 09 October 2007 23:37:53 radar.map35@...6..., vous avez écrit :
I made no convention as long i've done it alone, sometimes quite quickly and the best i could (especially at the beginning where i even didn't know docbook and other stuffs).
usually, i tryed to follow tool or command name but there are sometimes sub-section not realted to some UI object.
I see no trouble in doing a convention. I don't know if there is already one in gnome-doc project, but may be somethings like gnome icon naming project (or tango which is the same now i guess) could be a basis.
"
Icon Naming GuidelinesHere we define some guidelines for when creating new icons that extend the standardized list of icon names defined here, in order to provide icons for more specific MIME types, devices, or international flags.
* Icon names are in the en_US.US_ASCII locale. This means that the allowable characters in the icon names, must fall withing the US-ASCII character set. As a further restriction, all icon names may only contain lowercase letters, numbers, underscore, dash, or period characters. Spaces, colons, slashes, and backslashes are not allowed. Also, icon names must be spelled as they are in the en_US dictionary. * The dash “-” character is used to separate levels of specificity in icon names, for all contexts other than MimeTypes. For instance, we use “input-mouse” as the generic item for all mouse devices, and we use “input-mouse-usb” for a USB mouse device. However, if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic icon from the current theme is preferred, in order to keep consistent style. * Icons for branded applications should be named the same as the binary executable for the application."for ex :
document-new
edit-find
object-flip-vertical
we could at the same time do it for section ID but also for pictures. our trouble is were we wish to have several picture in a section : should we add a number or "--extrascomment"
Any opinion ?
For all your proposition on this mail : It's a good idea to see what other do. I agree at this organisation.
Thanks pygmee.
"radar.map35@...6..." <radar.map35@...6...> writes:
IMO, french and english don't really have to be exactly the same, nor a german...
But then you cannot use all the po tools anymore. I know that Christoph of Scribus is of this "local versions are free" opinion, but I think we don't have the manpower for that. I personally would translate/adjust some sentences when I have time, but I surely won't hunt down useful changes by hand.
IMO we need para-by-para consistency to get the user-manual started, unless suddenly 5 maintainers for each language pop up.
Cheers Colin
yep, i was not talking about buig differences but local, just to adjust a description to some specificities. So we mainly agree ;)
pygmee
But then you cannot use all the po tools anymore. I know that Christoph of Scribus is of this "local versions are free" opinion, but I think we don't have the manpower for that. I personally would translate/adjust some sentences when I have time, but I surely won't hunt down useful changes by hand.
IMO we need para-by-para consistency to get the user-manual started, unless suddenly 5 maintainers for each language pop up.
Cheers Colin
I am completely in agreement with this all, however, there are a couple of immediate roadblocks to working on content right now.
The first is that the English document is not set up exactly the same as the French - there are many differences in structure that I've already encountered. So we'll have to do some work to bring them in line somehow. This can begin by restructuring the two documents, but I think a much better way would be to work on creating a po template.
If we do work on a po template right now, I think it should be based on the French document entirely, since that document seems to be much more up-to-date. However, it's been difficult for me to determine which document to base my editing from since I don't really know what the most recent work is. While I would like to volunteer to start on po templates, I don't think I am in any way qualified, as I don't have deep knowledge of the syntax or of the user manual.
Which puts me at an impasse, since I don't think I can do a whole lot of meaningful work at the moment translating and updating the English version.
The second roadblock is that, if I am writing new content or updating old content, I feel like I'm bound by the structure that exists unless I get approval from one of you "senators" to change it, because that will also mean the French document structure has to change as well. For example, the Intro and SVG sections in the English are now completely rewritten by me as of last night, but they also have a new structure (which I believe was necessary to make them coherent). I threw caution to the wind and made the changes, which I'm now regretting following this discussion.
If I were to make a decision to work on something right now, my first instinct would be to copy the French xml doc into the new En doc separated files, copy all the useful English text back into the appropriate places, and then begin work. However, I know that as soon as I get all that done, someone can easily change the French document structure again, so we're back at the beginning problem. Which is why I suggested above that our next move should be to get po stuff into operation; and I think it's important enough that it should be done before any more content work is done. Otherwise, attempting work on more than one translation at a time and keeping the same document structure will be a nightmare that I really don't have the ability to be a part of.
I guess I would like someone to tell me what to do next so that I can do something that will be useful and won't foul things up until the document structure mess is sorted out.
I'm sorry, I don't mean to sound like an upstart, I just want to get some work done and help you guys and Inkscape; but I tend to be brutally logical.
JF
radar.map35@...6... wrote:
yep, i was not talking about buig differences but local, just to adjust a description to some specificities. So we mainly agree ;)
pygmee
But then you cannot use all the po tools anymore. I know that Christoph of Scribus is of this "local versions are free" opinion, but I think we don't have the manpower for that. I personally would translate/adjust some sentences when I have time, but I surely won't hunt down useful changes by hand.
IMO we need para-by-para consistency to get the user-manual started, unless suddenly 5 maintainers for each language pop up.
Cheers Colin
lo joshua
but I think a much better way would be to work on creating a po template.
we just begun working on a new outline of the manual this could be time to make things clearer : http://wiki.inkscape.org/wiki/index.php/UserManualOutline
If we do work on a po template right now, I think it should be based on the French document entirely, since that document seems to be much more up-to-date.
French is much more complete and up2date since i felt difficulties to write in english. We can keep french as basic version but it should immediately be translated to english since ther ewill much more english-speaking contributor than french speaking.
caution to the wind and made the changes, which I'm now regretting following this discussion.
let us read
If I were to make a decision to work on something right now, my first instinct would be to copy the French xml doc into the new En doc separated files, copy all the useful English text back into the appropriate places, and then begin work.
in fact, as english xml file will need to quite completely proof-read, feel free to do it the way you want. At this time, nobody else is working on the english version so you're free. Of course we can help you but you can read how we english ;)
I'm sorry, I don't mean to sound like an upstart, I just want to get some work done and help you guys and Inkscape; but I tend to be brutally logical.
np : the doc-team is quite new (since i was before that alone for years). So we just have to find our way. Your ideas are welcome.
pygmee
Le Thursday 11 October 2007 06:14:43 Joshua Facemyer / Impressus Art, vous avez écrit :
I am completely in agreement with this all, however, there are a couple of immediate roadblocks to working on content right now.
The first is that the English document is not set up exactly the same as the French - there are many differences in structure that I've already encountered. So we'll have to do some work to bring them in line somehow. This can begin by restructuring the two documents, but I think a much better way would be to work on creating a po template.
If we do work on a po template right now, I think it should be based on the French document entirely, since that document seems to be much more up-to-date. However, it's been difficult for me to determine which document to base my editing from since I don't really know what the most recent work is. While I would like to volunteer to start on po templates, I don't think I am in any way qualified, as I don't have deep knowledge of the syntax or of the user manual.
Which puts me at an impasse, since I don't think I can do a whole lot of meaningful work at the moment translating and updating the English version.
The second roadblock is that, if I am writing new content or updating old content, I feel like I'm bound by the structure that exists unless I get approval from one of you "senators" to change it, because that will also mean the French document structure has to change as well. For example, the Intro and SVG sections in the English are now completely rewritten by me as of last night, but they also have a new structure (which I believe was necessary to make them coherent). I threw caution to the wind and made the changes, which I'm now regretting following this discussion.
What is your new structure ? You are, actually, only on the english version, so you're free.
If I were to make a decision to work on something right now, my first instinct would be to copy the French xml doc into the new En doc separated files, copy all the useful English text back into the appropriate places, and then begin work. However, I know that as soon as I get all that done, someone can easily change the French document structure again, so we're back at the beginning problem.
We are 5 (pygmee, you, Alexandre, Colin and me to have access to commit who make change in the manual). So just tell us (here) what you have change and want to keep,(like the content), let me see (let us see) if i (we : pygmee and i) think it was a good idea to make this change in french and after nobody will change that. Furthemore, i prefer update the manual and not change the new work recently add. Then you very free :)
Which is why I suggested above that our next move should be to get po stuff into operation; and I think it's important enough that it should be done before any more content work is done. Otherwise, attempting work on more than one translation at a time and keeping the same document structure will be a nightmare that I really don't have the ability to be a part of.
Are you on irc ?
I guess I would like someone to tell me what to do next so that I can do something that will be useful and won't foul things up until the document structure mess is sorted out.
I'm sorry, I don't mean to sound like an upstart, I just want to get some work done and help you guys and Inkscape; but I tend to be brutally logical.
JF
I've taken a look at the manual outline page on the wiki, and I worked a little on it last night.
I was wondering if there's a desire to completely restructure the document?
Anyway, I sat in front of Inkscape and came up with an as-yet-unfinished draft just by looking at the program and trying to determine how I would go about teaching someone Inkscape, from the most basic to the most advanced things. I personally like this approach because it allows someone to use the manual to learn more intuitively than by jumping around to different sections to get the basics.
The drawbacks would be that it can be slightly disorganized in some ways (but I think that problem can be minimalized with a little care) and that it's a little more difficult to make sure that every feature is included (since it's not a straight run-through of the menus, however this is also something that can be easily dealt with if we're careful).
So here's a very rough draft. I'm not all that attached to most of the order, it's just what came to me.
If nothing else, it's at least a step towards a full list of features.
If you gentlemen/woman (is there only one woman?) are interested, I'll do some finishing work and post it to the wiki page. If you have any suggestions, I'm open to them - especially if you see that anything really important is missing.
----------------------------
Introduction to Inkscape About SVG State of available SVG software Inkscape Goals
Introduction to the Interface (no real depth here) Using the mouse & Keyboard Working with the canvas Working with simple objects Basics of object properties Opening / Saving files Elements of Interface Menus Toolbars / Bottom bar Dialogs How they work (or Different types: Floating / Sidebar) How to use them
Toolbox (In depth, but limited to what you can do simply by clicking on the tool and using its toolbar controls) Selector Node Tool Sculpt Tool Magnification Tool Object Tools Box Tool Elipse Tool Shape Tool Spiral Tool 3D Tool Drawing Tools Pen (Pencil) Tool Bezier Tool Calligraphy Tool Engraving Tool Paint Bucket Text Tool Diagram Tool Color Tools Gradient Tool Dropper Color Selector (Not really in the Toolbox, but makes sense here - however, I think plans are to do something different with it)
Advanced Topics (Stuff in menus and dialogs) Fill / Stroke Effects Filter (Different from path effects?) Path Raster Layers Object Operations Path Operations Grouping Copying / Cloning Transforming Aligning Text (Detailed) Input (Mouse, Keyboard, Pen Tablet, Telekinesis :) Import / Export / Saving As (detailed)
Super Advanced Topics ("Power User" stuff, hidden options, etc) Color Profiling Whiteboard
On 10/12/07, Joshua Facemyer / Impressus Art wrote:
I've taken a look at the manual outline page on the wiki, and I worked a little on it last night.
I was wondering if there's a desire to completely restructure the document?
Definitely yes. I also have a new outline in works. Will comment on yours a tiny bit later ;)
Alexandre
Alexandre Prokoudine wrote:
On 10/12/07, Joshua Facemyer / Impressus Art wrote:
I've taken a look at the manual outline page on the wiki, and I worked a little on it last night.
I was wondering if there's a desire to completely restructure the document?
Definitely yes. I also have a new outline in works. Will comment on yours a tiny bit later ;)
Alexandre
I got my new outline proposal on the wiki last night. Please feel free to comment.
I'm interested to see what Alexandre has in comparison. I'd love to get started on making a po template, if we can work out an outline format soon.
JF
participants (5)
-
Alexandre Prokoudine -
Colin Marquardt -
Elisa-yemanja -
Joshua Facemyer / Impressus Art -
radar.map35＠...6...