Hi Sylvain, 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. 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 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 memory. 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". ((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.)) Maybe Martin and/or Maren can give updated and/or more technical answer for that? 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. 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!! 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? I can't answer #3. All best, brynn -------------------------------------------------- From: "Sylvain Chiron" <chironsylvain@...102...> Sent: Thursday, June 02, 2016 5:07 PM To: "Inkscape translators" <inkscape-translator(a)lists.sourceforge.net&gt;; "Inkscape Docs" <inkscape-docs(a)lists.sourceforge.net&gt; Subject: [Inkscape-docs] Questions concerning the website's content

On Fri, 2016-06-03 at 08:27 +0200, Sylvain Chiron wrote: 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 too. If you change H1, h2, h3 styles, just remember to be specific in your css and say .page h1 { ... }, so that the styles won't change non-cms content pages. (unless that's what you want to do of course) You can email me updated css files if you're not sure about patching or merge requests. Martin,

Dear Sylvain, Am 04.06.2016 um 16:55 schrieb Sylvain Chiron: - 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. - Please make the new rules more specific. Your changes will change *all* h2 and h3 on the website. 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. So this means as a general rule you'd need to - check if there are other parts in the code that will be concerned by a change (hint: there are lots of them! Use search/grep on all .html files with '<h2' as query) anywhere in our templates, and if so: - add separate rules, or make sure it looks okay first with all pages that are concerned by the change. In this case, I think we'll need two new rules that set the margins for cms headings differently than for the usual headings. Kind Regards, Maren

Dear Sylvain, Am 04.06.2016 um 18:40 schrieb Sylvain Chiron: - I agree. Thank you for starting out on this! - I just had time to look up the bug I was thinking of. Fortunately, it was about specific *nested* plugins not showing up when the translation doesn't have any plugins, so it's not relevant here. - Yes, that's what I meant by "as copy-paste for links or images between plugins might not work as expected". Nested plugins are saved as children of other plugins. When removed from their original place, and pasted into another one, I assume that they will be gone, because they are deleted from their original place. - So I agree that's a lot of work. Only you can decide if it would be worth the gain for you. I can work with both situations, and I think Brynn can, too. It might make work a tiny bit faster, but not enough so that I would want to do the splitting myself. Maybe there's something else that would profit from our time investment more than this? We've got enough bug reports for inkscape-web to have work for a couple of months... You seem to like javascript stuff, so maybe the inbox problems or the TOC customization could profit from your work. Before you start working on any bug, please add a comment there, telling the others that you plan to work on it (so we don't work on the same bug at the same time), and also sketch roughly what you'd do to fix it. We can then give feedback, or add some more info to the report before you start working on it. Sometimes, things have changed since the bug was first reported, or we may know or plan something that you cannot know about. Kind Regards, Maren

Hi Brynn, Am 05.06.2016 um 02:47 schrieb Brynn: - Just turned this into a bug report: https://bugs.launchpad.net/inkscape-web/+bug/1589280 - We could review the style of those while we take a look at the other headings. Added that to the report. But first we'd have to make sure those styles will only be used for CMS pages. Regards, Maren

Yes, I understand it now. Apparently you and Maren and Martin can add new questions, as well as answers. But I can't add new questions - only answers, because I can't edit the code. The TOC is frustrating for me, because I originally typed/edited everything on the page (by writing the html directly, which I find enjoyable). But like so many other parts of the website cms/django, it very much limits what I am able to do. Now, except for minor edits, here and there, all I can contribute is comments about the website content. By now, most of the website is controlled from a level that I don't have access to, and couldn't use it, even if I did. When I first created that page, the only plugin available (to me) was Links. At first, I didn't use it at all, because it didn't work. But later, we found the problem was one of my Firefox plugins that blocks the referrer header. So then, I was able to fix all the links. All best, brynn -------------------------------------------------- From: "Sylvain Chiron" <chironsylvain@...102...> Sent: Friday, June 03, 2016 12:27 AM To: "Brynn" <brynn@...78...> Cc: "Inkscape translators" <inkscape-translator(a)lists.sourceforge.net&gt;; "Inkscape Docs" <inkscape-docs(a)lists.sourceforge.net&gt; Subject: Re: [Inkscape-docs] Questions concerning the website's content > 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 >> memory. > > 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 > the file. > >> 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: > http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development > 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.: > https://inkscape.org/en/develop/debugging/ > 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: > http://bazaar.launchpad.net/~inkscape-webadmin/inkscape-web/inkscape-web/... > 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!! > > 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 &eacute; and the source code becomes > really difficult to read. There are also many apostrophs which become > &#39;. And many different accented letters: à è ê ô î â û ë ï and > capital variants. > >> 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? > > https://inkscape.org/en/download/?edit > Do you see any gap? > -- > Sylvain