Dear fellow website translators,
the English FAQ has been updated, to
- add info about JPEG export
no complete diff screenshot available)
- improve info about background color export
, see attached screenshot)
And Martin is currently working on improving the CMS diff capabilities,
so maybe this job of regularly posting updates to the list will soon be
'automated away', as the website can then produce its own diffs.
When that's available, I'll ask you all to subscribe to page updates
instead. I'll make a feature request that we can restrict subscription
to specific languages then, so you won't get tons of emails for each
edit made to any language.
Dear fellow Inkscape website translators,
we've got a new news item:
There's a lot going on currently in the Inkscape project :)
Hope you can spare some time beside the release preparations work, but
if you need to decide, please prioritize the software translations ;-)
Thanks a lot for your help,
Hi to all, thanks to Maren I notice a wrong string on ui/tools/measure-
tool:cpp on line 781.
Te change is:
"Add Stored to measure tool" become "Keep last measure on the canvas,
Sorry for the inconveniences.
All the best, Jabiertxo.
Dear fellow Inkscape Website Translators,
which describes where the project currently is in the release process
for 0.92 has been updated with some fresh info from Bryce.
(status changes, added feature list, modified text that links to release
nots, removed 'notable bugs' section)
I expect there will be more updates for this page in the following
weeks, but most other ones will presumably only consist of adding a
class="done" to the list items to make them green.
Thanks, everyone, for your work on the website,
Dear Inkscape Program Translators,
a few days ago, Bryce sent the following to the development mailing
list, and I think the 'translation' part is probably of interest to you.
Am 25.05.2016 um 22:25 schrieb Bryce Harrington:
> Another pre-release is now available for testing from the source
> downloads page:
> The release is:
> 0.92pre1 Source Tarball Bzip
> This is an early preview of our upcoming release and as such can be
> expected to have some stability issues or incomplete features. See
> Inkscape's bug tracker for a list of known issues.
> == Translation ==
> We are now in String Freeze. All translators should strive to bring the
> language files up to date.
> Please aim to get all translation work committed by mid-June.
> == Packaging ==
> Packagers for Linux, Windows, and OSX should use this source tarball for
> creating packages for their respective platforms. I strongly urge all
> packagers to test their packaging scripts at this time and generate
> packages for pre1. Please report to this thread with your status in
> getting the packages made, so I can identify where help is needed.
> Note that this was produced using the new cmake system, and the
> autoconfig build files are not included in this dist; if you require the
> autoconfig system for your platform you can still generate an autoconfig
> tarball from our VCS trunk, however you should prioritize shifting to
> cmake as we will be dropping autoconfig in the future 0.93 release.
> I plan to continue post further pre-releases on a roughly 1-2 week
> cadence until we feel the codebase is stable enough for the final
> release, which would be late June at the earliest.
> == About Screen ==
> Hopefully a contest for the about screen should start up soonish?
> In the interim, and as a contingency in case it doesn't happen, could
> someone modify the 0.91 about screen to say 0.92pre?
Le 04/06/2016 à 17:44, Maren Hachmann a écrit :
> Am 04.06.2016 um 16:55 schrieb Sylvain Chiron:
>> Le 03/06/2016 à 17:28, Martin Owens a écrit :
>>> I can say that you should consider any new website design to be frozen
>>> and you can sort on any part of the design for the website for
>>> incremental improvements. I've been ding that for the past few months
>> Do you mean ‘shouldn't’? That's OK.
> - Sorry for chiming in, Martin.
> Sylvain, what he means is that there are no current efforts going on for
> a revolutionary redesign of the page. But we can make small changes to
> improve the current design.
Okay… Strange language. That's understood.
> We do only want to change those inside the cms pages. All other h2 and
> h3 headings (unless there aren't any? You could check that first, to see
> if this is necessary) must stay the same.
There are others actually, but they all redefine their own margin and size.
Wait… OK, you're right, there are many headings elsewhere — :).
There is no overriding rule here:
So I'll make different rules: ‘.wrapper h2’ and ‘.wrapper h3’.
Le 03/06/2016 à 19:48, Maren Hachmann a écrit :
> If you do make this change, it would help if you could also take some
> time to remove (at least a few of) the paragraphs when the fix has been
> released, so the pages will not look weird due to huge gaps between the
> headings and the following texts.
I don't think there's a need to wait. I'll remove the paragraphs right
now except in the FAQ for which I'll wait.
>> 2. It is quite hard to find the part we want when editing the FAQ; could
>> we subdivide the only text plugin in several text plugins, one for each
> - That's an option. Before we continue to discuss if it is to be
> implemented, please research if those plugins must then also be added to
> all translations.
I think there's no link between text plugins in different languages.
Optionnally, only translators who want several text plugins could subdivide.
> It may be that missing plugins will automatically be substituted by
> their English counterparts (I think due to a bug in current django, this
> does not happen, but as soon as they fix the bug, there could be a
> problem - there was something about this in their bug tracker, I seem to
You mean that if we try to take the links from a text plugin to another,
we may get the English links (as the plugins will remain childs of the
initial text plugin)?
However… If we try to move the plugins from a text plugin to another, it
will simply remove the plugins' data and the plugins won't exist in the
second text plugin (I just tried on the sandbox)… Thus it would be a
very difficult task to subdivide as I thought…
> I could imagine splitting the FAQ into its major 7 sections, but having
> a single one for each question would make editing a bit annoying (also
> it's too much editing work to put that change in, as copy-paste for
> links or images between plugins might not work as expected).
Yes, I was talking about a splitting for the major sections.
Le 03/06/2016 à 05:45, Brynn a écrit :
> For #1, I brought this up a long time ago. Well, something very
> similar (I think it was the h3 style I wanted to tweak, or maybe
> h4.....). I think the text styling needs an overhaul....or at least a
> tweak. Styles, and maybe even some classes or IDs, etc. too. The reply
> at that time was that we were considering a new website design in the
> foreseeable future. Although it seems like it stays in the distant
> future, and doesn't get closer. But the response was let's talk about
> it when we are getting a new design.
Sure, we could have a better design… Currently pages' content is a bit
blunt. I don't think it's the right moment as the focus is on the 0.92
release. We could work on it in a few months if you want.
I also have other work, such as translating that FLOSS manual…
> There's a good chance that I put most of those empty paragraphs
> in there. The pages, and especially the pages with a lot of text, come
> across as imposing -- the wall of text, as they say. So I think they
> are the best we can do currently. I would not want to remove them until
> we have a good replacement. Do you think visitors to the site recognize
> that it's an empty paragraph? I don't see how they could know the
> difference, unless maybe if they are website designers
If they are a bit interested in style, typography or semantics like I
am, they will notice that some headings have more space above them than
others, and they will now that use of an empty paragraph to add more
space in computer writing (most probably think it's a good use).
They can also inspect the DOM (the document tree), of course.
> Are the changes you suggest something that could be made easily?
> I'll have to refresh my html, and dig in a little bit, to understand
> specifically what you mention. In general, I understand what you're
> saying. But as far as the code itself, that's not in the front of my
Yes, this is a very simple change, I can commit it within one minute.
To understand what I meant, just right-click on a heading, and click the
last menu item ‘Inspect element’. The inspector should appear, showing
the document tree, and the tag/node for the heading you right-clicked
will be selected. The styles that apply to the selected node are shown
on the right.
The style property I refer to is ‘margin’.
In Firefox at least, you should see ‘main.css:line number’, indicating
the place where the rule is defined. If you click on it, you'll go to
> If the changes can be easily inserted into the css, I'd say let's
> do it. But in this case, one change may lead to another and another.
> So maybe better to wait until everyone is focused on the new design? At
> least that's what I like to call "my simple-minded thoughts".
I think we can just do it because I'm very focused on the
typography/semantics of the website and this is quite annoying…
> ((We (Sylvain and I) might not have had a formal introduction.
> So just for general info.... I do not have a local installation of the
> website. The only code I know is simple html, and my understanding of
> how websites work is fairly general and non-technical. (For example,
> this caching that's been mentioned so much lately -- I only understand
> the definition of "caching" and not what happens technically with the
> server.) I can add and edit the site content, using the django wysiwyg
> and/or the source/html. And I can join discussions about the content.
> But I hardly have any understanding of the programming side, with the
> trunks and commits and all.))
About the commits, the wiki has some info:
Then I joined the project and submitted two things: a fix for the ‘TOC
nesting bug’ I detailed previously, and a fix in style to avoid overflow
of preformatted blocks, using a scrollbar — see e.g.:
Therefore I had such an introduction…
However I don't have a local installation of the website as the Python
scripts don't work with me (I didn't emailed Martin about it yet, I'll
do it), and I avoid using it as it is very hard to use with my ten-year
slow computer. Fortunately I can often look carefully at what I wrote
with autistic abilities, and prove its exactness.
About caching, well, if you know the English word (I've only known the
use in computing for a long time), this is it: the website server must
compute many things to have the document it finally deliver to the
visitor. To avoid redoing those same computations for each visitor who
looks at the very same page, it caches some results to deliver them
automatically, until the variables are effectively changed (in a perfect
world). I don't have many details about what is cached for the Inkscape
website but this principle is usually sufficient to understand everything.
The ‘trunk’ is usually unique — it is the main development branch for a
project. What is a branch? When we want to develop a feature, we might
break the project. The next person who want to develop can't wait for
our feature to be ready to start to develop their own one. So both
developments are started from a state of the project that is known to
work. Then we divide the development progress in two ‘branches’ and we
will ‘merge’ them when both will be ready, to get a project with two new
cool working features. Well, life with branches is much more rich and
complex, but this is the basic idea. A ‘commit’ is the process of
submitting a change to a branch.
Am I clear?
> Maybe Martin and/or Maren can give updated and/or more technical
> answer for that?
I should have enough…
> For #2, I created the vast majority of what we have on the FAQ
> page today. (Well, the text anyway. It used to be straight html with
> anchors, but Martin installed a TOC plugin a few months ago. Now we can
> only edit the answers. If we need to add a new question, we have to ask
> Martin to do it.) I updated it from the old version, which I think is
> still existing in the wiki. (I made an updated version for the
> developers on the wiki too, but they apparently weren't interested in
> updating it. So it stays out of date.) Anyway, at that time, I had the
> option to have it all on one text block, or divided over 2 or more.
Thanks for your investment in the FAQs. I followed the story of the
apparition of the TOC, don't you remember?
About that TOC plugin, it seems you really didn't get it… even if we
tried to explain. This plugin is a wonderful thing: it generates the
anchors itself from the page contents. Then the writers don't have to
mind the TOC when adding sections. You can totally add new questions to
the FAQ without any problem. The anchor will appear in the TOC. You
don't even have to set an ID to the heading (unless your heading has
exactly the same title as another one).
Just look at this script which is delivered with the website's pages:
Lines 22–26 say: when the document is ready, if there is a (single)
#toc, then initialise anchors. The description of the way to do it is
from line 35 to 83. Line 39 says: iterate over every heading in
.wrapper. Lines 44–54 say: pick an id for the current heading. Line 69:
add an anchor in the TOC as a list item leading to the heading.
> For myself, it was better to have it all in one block. Most of
> the time, I worked on it locally in a text editor, and then pasted back
> in to save/publish. The text editor makes it so much easier, because it
> has the formatting, numbered lines, find/replace, etc. Ssooo much easier!!
Okay, but then, how can you edit the plugins? This is the main problem.
Another thing that bothers me is the forced use of HTML entities by the
CMS in the source code. In English you mostly have simple letters so
that's not a problem, but e.g. in French you have many accented letters,
and the very frequent ‘é’ becomes é and the source code becomes
really difficult to read. There are also many apostrophs which become
'. And many different accented letters: à è ê ô î â û ë ï and
> And so for myself, it's still better to have it in one block.
> And I would be happy to take on the responsibility to edit that page, if
> folks send me the info. However, on the other hand, I do understand
> that might not be the best scenario, logistically, for the project as a
> whole. So if everyone wants to break it up, I certainly would not
> object. I wonder if that can be done in a seamless way? Wouldn't there
> be a gap between blocks?
Do you see any gap?
Dear Inkscape translators,
the Inkscape docs (man page, tutorials, keyboard and mouse shortcut
reference) have been updated for Inkscape 0.92 and jazzynico told me
they are ready to be translated.
You can find them at
While the translation statistics list at
a bit outdated, it will, for most languages, still contain current info,
as there haven't been a lot of people working on them within the last
year or so.
So if you've got some time to give, give them some translation love, so
new users will find good documentation.
Dear fellow website translators,
Brynn has made a small update to the FAQ item about gaps caused by
antialising, see attached screenshot.
Thank you, everybody!
Special greetings go to Portugal and France, where our most active
translators are :)
I have three questions concerning the website's content.
1. For more space and better reading, headings (h2) are often preceded
by an empty paragraph, e.g. in:
This is true that pages are harder to read without that space; see:
However I have something against that practice of the empty paragraph; I
feel it as wrong semantic. Couldn't we simply add more margin at the top
of these headings? I suggest 4ex (it's currently 1.5ex).
We could also increase the margin-top of 3rd-level headings (from 1.5ex
Then we should remove those empty paragraphs (in the source form of
2. It is quite hard to find the part we want when editing the FAQ; could
we subdivide the only text plugin in several text plugins, one for each
3. Is it possible to translate the two following pages, or will it be
* https://inkscape.org/fr/teams/ (and why not teams themselves)
Everyone may give their opinion about the first two questions; the last
one is for those who know…