KiCad uses semver "approximately".
I am not quite sure if I understand the question correctly, but the docs
branch names *are* synchronized with the code at the moment.
The 6.0 docs branch is the stable one, and master is the nightly (6.99) one.
-Jon
On Mon, May 2, 2022 at 8:47 AM Marco Ciampa
The English screenshot is out of date; we removed the option to import
old library configurations as it resulted in broken library
configurations for too many users.
On Sat, Mar 19, 2022 at 10:49 AM Marco Ciampa wrote:
>
> Hello devs,
> in these days I was forced to stay home for a few days for
On Sat, Nov 27, 2021 at 05:38:54PM -0500, Jon Evans wrote:
> > As you might know, there is a chapter in the documentation called Getting
> > Started in KiCad [1] which is at this point entirely out of date and does
> > not really cover the modern KiCad workflow. I have seen man
As you might know, there is a chapter in the documentation called Getting
Started in KiCad [1] which is at this point entirely out of date and does
not really cover the modern KiCad workflow. I have seen many people point
new users at various video series or posts on the user forum as more
Hi BK and welcome!
Starting with Weblate sounds like a good plan. Right now the user manual
(English sources) is being (slowly) re-written to prepare for 6.0 RC
(expected hopefully in the next few months).
So, it might be good to only translate the updated parts (mostly just the
"kicad" and
Jon
[1] https://gitlab.com/kicad/services/kicad-doc/-/merge_requests/809
[2] https://github.com/Mogztter/asciidoctor-web-pdf
On Sun, Feb 21, 2021 at 6:24 PM Jon Evans wrote:
>
> By suggestion of someone on the asciidoctor list I tried
> asciidoctor-web-pdf which uses nodejs+puppeteer to
a promising approach.
Sample PDFs (with the default stylesheet) are attached in the MR recent comment:
https://gitlab.com/kicad/services/kicad-doc/-/merge_requests/776#note_513840519
-Jon
On Sun, Feb 21, 2021 at 9:43 AM Jon Evans wrote:
>
> Hello Carsten,
>
> On Sun, Feb 21, 2021 at 2:3
Hi all,
In [1] I introduced a "prototype" of a section that should not be
translated automatically.
I don't really understand our translation pipeline very well (using
gettext to translate each document through chunks seems kind of
strange to me, to be honest -- it seems like it would be easier
Hi all,
I'm going to try to get the work Johannes started[1] complete so we can
move to asciidoctor.
Right now the main blocker is CJK font support. You can see more details on
the MR; I'm going to reach out to asciidoctor community to see if anyone
has a working solution for this other than the
It sounds like the effort to move to asciidoctor is renewed anyway, see
https://gitlab.com/kicad/services/kicad-doc/-/merge_requests/776
Let me know if I can be any help!
Best,
Jon
On Sat, Feb 20, 2021 at 11:12 AM Marco Ciampa wrote:
> On Sat, Feb 20, 2021 at 09:50:37AM -0500, Jon Evans wr
at, Feb 20, 2021 at 9:39 AM Jon Evans wrote:
> Thanks Marco!
>
> On Sat, Feb 20, 2021 at 6:42 AM Marco Ciampa wrote:
>
>> On Fri, Feb 19, 2021 at 06:38:40PM +0100, Marco Ciampa wrote:
>> > On Fri, Feb 19, 2021 at 10:09:37AM -0500, Jon Evans wrote:
>> > &
Thanks Marco!
On Sat, Feb 20, 2021 at 6:42 AM Marco Ciampa wrote:
> On Fri, Feb 19, 2021 at 06:38:40PM +0100, Marco Ciampa wrote:
> > On Fri, Feb 19, 2021 at 10:09:37AM -0500, Jon Evans wrote:
> > > Hi,
> > >
> > > This commit
> > >
> http
Hi,
This commit
https://gitlab.com/kicad/services/kicad-doc/-/commit/89a83d8ee761f8ebc57ef47061c8cd818e68bdd8
Is causing generation of the Polish PDF version of the Pcbnew docs to fail.
The issue looks superficially similar to
https://github.com/KiCad/kicad-doc/issues/741 but I have no idea how
Anyone have tips for building the documentation on Windows?
I have tried the following in msys2 (from a ./build directory)
cmake -G "MinGW Makefiles" -DLANGUAGES=en -DBUILD_FORMATS=html
make
Both cmake and make run with no errors, but no output is present in the
build folder.
Make exits very
Good suggestions, Marco!
Regarding translations:
1) If we move chunks of text from one doc to another, is it easy to keep
the translations updated?
2) For the V6 documentation effort, is it best to do things gradually while
translators work in the background, or having a "documentation freeze"
, etc) may not be the
right "arrangement of chapters"
-Jon
On Sat, Sep 26, 2020 at 7:43 PM Heitor wrote:
> On Sat, 26 Sep 2020 16:11:40 -0400
> Jon Evans wrote:
>
> > To take my idea a bit further:
> >
> > If we did this, I would suggest we change a
Oh and one thing I forgot: The "Getting started" section would also include
the basic introduction to the KiCad project manager and how to create
projects.
On Sat, Sep 26, 2020 at 4:11 PM Jon Evans wrote:
> To take my idea a bit further:
>
> If we did this, I would suggest w
with the most common workflows and talk about advanced or
uncommon workflows at the end of a section.
-Jon
On Sat, Sep 26, 2020 at 4:07 PM paul...@hoevendesign.com <
paul...@hoevendesign.com> wrote:
> On Sat, 26 Sep 2020 15:25:18 -0400
> Jon Evans wrote:
>
> > Hi docs t
>
> 5) Creating and Managing Libraries
>
> 6) Configuring and Customizing KiCad
>
>
>
>
>
> Best Regards
>
> Neil
>
> *NH Designs*
>
>
>
>
>
> *From: *Jon Evans
> *Sent: *26 September 2020 22:25
> *To: *kicad-doc-devs@lists.launc
Hi docs team,
6.0 Feature Freeze is around the corner. Once that hits, I plan on
investing some time in updating the docs, especially for features I've been
involved with developing.
Are there any big architectural changes to the docs coming that I should
wait for before starting this effort?
one have shown interest in actually using that as an excuse to even
> maintain master. See https://github.com/KiCad/kicad-doc/issues/719
>
> Jon, you can decide if we want to branch from 5.1.2 or
> 814321ecf474f2c1a6061a01122c9b3148b17a2e. I have pushed the 5.1 branch
> I have with merge-bas
Why not just not translate the master docs branch (if you start using
branches)?
It seems OK to just keep it in English as long as the docs are in
development alongside the code.
Then when the feature freeze happens the translation can start.
-Jon
On Thu, May 7, 2020 at 1:17 PM wrote:
>
>
FWIW, I would help write documentation for the bleeding edge code that I
work on, if there were a branch to do it in.
I don't want to do that today without a branch because I don't want to
manage carefully writing the documentation to apply to both 5.1 and
bleeding edge.
I agree with Carsten's
Perhaps any such split would have to wait until we feel good about the
state of the documentation as it applies to the stable release version.
On Fri, Jan 10, 2020 at 11:03 AM Wayne Stambaugh
wrote:
> On 1/10/20 10:59 AM, Jon Evans wrote:
> > How often would we actually cherry-pick s
wrote:
> > On Thu, Jan 09, 2020 at 08:11:38PM -0500, Jon Evans wrote:
> >> My view is that the development team (including those working on code
> and
> >> those working on documentation, sometimes the same people and sometimes
> >> different) need a place to stage
I think the drawbacks here are enough to make me unsure if this adds enough
value. This would mean we could only add new documentation, and could not
remove or edit documentation that is out of date in master.
I agree with Marco that it would be best if there were two doc branches
(stable and
.
>
> IMHO not having new features documentation ready for nightly build users
> is not a big deal, they are brave enough to live on the edge, they can live
> without documentation :-)
>
>
> - Mail original -
> From: "Jon Evans"
> To: "f dos santos&quo
Some previous discussion: https://github.com/KiCad/kicad-doc/issues/719
On Thu, Jan 9, 2020 at 6:45 PM wrote:
> Hi,
>
> People can say that some documentation are outdated but for buses
> connections it's the other way around.
> I'm pretty sure "indated" it's not a word ;-)
>
> The eeschema
Is a good general approach here to use more tooltips for longer strings,
and make strings that are part of the UI layout as small as possible?
On Tue, May 28, 2019 at 2:21 PM jp charras wrote:
> Le 28/05/2019 à 20:00, Carsten Schoenert a écrit :
> > Am 28.05.19 um 19:48 schrieb Seth Hillbrand:
29 matches
Mail list logo