Update the language translation source '.ts' files with the
translatable strings in the source code with the following command:
$ make translation
This effectively runs the following command:
$ pylupdate5 -noobsolete i18n/manuskript.pro
After updating the '.ts' translation source files from weblate,
compile all of the language translations into '.qm' files.
This was done with the following command:
$ make i18n
This effectively runs the 'lrelease' command on each '.ts' file. For
example:
$ lrelease i18n/manuskript_es.ts
Two separate pull requests indicate an issue translating the warning
for when an import is attempted with PyQt/Qt versions 5.11 and 5.12.
As such change the warning message.
See PRs #668 and #701.
The Travis CI builds for macOS X are failing because there are no
Homebrew bottles (packages) for macOS X Sierra (10.12).
The error message in the Travis CI log is:
...
# Upgrade to python 3.x
brew upgrade python
Warning: You are using macOS 10.12.
We (and Apple) do not provide support for this old version.
...
Note that by default the Travis CI will terminate a build after 10
minutes if no output has been received. Unfortunately building qt
from source code may take hours, so installation using a Homebrew
bottle is required.
To address this issue, choose a macOS X version that has a Homebrew
bottle for qt [1].
[1] https://formulae.brew.sh/formula/qt
The homebrew project currently lists having a qt bottle for:
- Catalina (10.15)
- Mojave (10.14)
- High Sierra (10.13)
No bottle is listed for macOS Sierra (10.12)
In order to support as many versions of macOS X as possible, choose
the lowest osx_image value [2] that is currently supported with a
homebrew bottle.
[2] https://docs.travis-ci.com/user/reference/osx#os-x-version
At this time osx_image value xcode9.3 is listed as supporting OS X
10.13.
Unfortunately xcode9.3 did not work in the Travis CI build.
By following the suggestions for troubleshooting homebrew [3] a
discovery was made that a higher value of xcode10.1 was required.
[3] https://docs.brew.sh/Troubleshooting
Suggestion was to use "brew update" twice and "brew doctor" twice.
The messages in the log were as follows:
...
Warning: Your Xcode (9.3) is outdated.
Please update to Xcode 10.1 (or delete it).
...
Now try setting osx_image value to xcode10.1 which is listed as
supporting OS X 10.13.
QtCore.Qt.GlobalColor does not have any accessors for the predefined
colors on PyQt versions before 5.11 despite the object itself existing.
It would have been nice if the documentation* had mentioned that object
being broken on older versions, but I should have tested with even older
versions of PyQt before submitting the original patch.
Apparently the most supported way to access these colors is through the
Qt namespace itself, but those aren't documented in the slightest. Ugh.
My apologies to all those affected. Fixes issue #659.
*: https://www.riverbankcomputing.com/static/Docs/PyQt5/api/qtcore/qt.html#GlobalColor
Update the language translation source '.ts' files with the
translatable strings in the source code with the following command:
$ make translation
This effectively runs the following command:
$ pylupdate5 -noobsolete i18n/manuskript.pro
After updating the '.ts' translation source files from weblate,
compile all of the language translations into '.qm' files.
This was done with the following command:
$ make i18n
This effectively runs the 'lrelease' command on each '.ts' file. For
example:
$ lrelease i18n/manuskript_es.ts
A previous fix (5f9ea3) inadvertently broke the progress bar by
converting to the wrong data type. (See issue #561 / PR #609).
While checking the code I realized the problem occurred primarily
because we weren't checking the validity of the values closer to the
source. Doing so alleviates the need to check elsewhere.
In the hope of inspiring a more systematic approach, a new uiParse()
utility function has been added to curb the further growth of toXxx()
functions that exist solely to validate user input.
There is no doubt room for improvement, both on the end of the new
uiParse() function as well as the spot where it is used. Ideally, the
data that comes out of the model should already be 'safe', but since
this is a bugfix for a bugfix I want to keep waves to a minimum.
This commit fixes issue #652.