0.5.0 was moving in the direction of treating everything like a simple
list. 0.4.3 had some bugs that made complex lists look closer to the
spacing that complex lists use. This resolves both and adds specific
item margins for both cases.
See https://docutils.sourceforge.io/sandbox/html4strict/data/simple-lists.html
The HTML4 writer depended on the `.last` selector, a class added by
Sphinx directly on output. Both writers are not using that method
anymore and instead relying on well supported CSS selectors.
This actually also addresses a number of inconsistencies with margin
spacing in lists. Version 0.4.3 and prior have a number of odd issues
around nested lists that are resolved with this change.
Currently, python method parameter/etc field lists are the same class as
general field lists, so we can't treat them differently. This reverts
styling the field list without the colon for now, and is comparable to
how the HTML 4 writer outputs field/parameter lists.
The fonts loaded in 0.4.3 did not have a configuration for the CSS
`font-display`, and they were switched to `font-display: swap` in
0.5.0rc1. The old behavior was FOIT, and `swap` changed the behavior to
FOUT, which was more noticeable. This changes back to a long block
period while the fonts are loading.
For more information on the FOUT/FOIT and the font-display mechanism:
https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display
This is a release candidate for 0.5.0, which adds support for both HTML4
and HTML5 writers, which should support the default writer regardless of
your version of Sphinx.
Also included in this release are localization efforts and 10 language
translations.
You will need to specify the release manually to test, if there are no
major issues, we will have a 0.5.0 release shortly.
Closes#886Closes#712
I moved the configuration to setup.cfg, with the rest of the tooling
configurations.
I had trouble getting the parsing to work for both the current pattern
that exists in this repository (`0.4.3.dev0`), and the pattern we use in
other repositories (`0.4.3alpha1` and `0.4.3rc1`).
The release pattern would potentially be:
* Version is `0.4.3alpha1`
* Bump to `0.5.0alpha1` or `0.5.0rc1` for testing release, `0.5.0` for
full release
* Commit, tag, etc the new release
* Release to PyPI
* Bump to `0.5.1alpha1` and commit. This is the next development release
that would be in `master` branch
This uses the transifex changes in #911 to regenerate all of the files
from transifex. Any differences in the translated files should be
handled at transifex, as it looks there were some manual translations
that were overridden in this process.
This uses force mode to download po files, always. Normal operation is
to use the file modification date for comparison, which doesn't work
because of Git.
This also sets `onlyreviewed` mode, which will omit strings which are
not translated yet. This will result in the underlying source
translation being used in place, until the string is reviewed in
transifex.
