Recent commits to derivepassphrase.git (220d71df817f2662308efab15e98f138fd6dde18)

Fix coverage

2024-12-31T23:58:59+01:00

Exclude further machinery from coverage that isn't meant to be tested.
</pre>

Reimplement `--help` and `--version` options in a translatable way

2024-12-31T22:30:36+01:00

Reimplement the machinery for displaying help texts and version
information, supporting translatable strings.  Besides the one-line help
texts for the `--help` and `--version` options, the version information
text is a translatable string itself, in case the name and version
number should be rearranged, or prefixed or suffixed, or whatever.
</pre>

Replace strings in `derivepassphrase export vault` with translatable ones

2024-12-31T22:18:29+01:00

Apparently, we overlooked this in
59d73c8320650a6bcb77eed759c694949d350cdb.
</pre>

Force logging calls in error callback to be uninterpolated

2024-12-31T22:08:02+01:00

Remove the `args` argument to the error callback and to the underlying
`logging` function, forcing logger to skip log message interpolation in
any case.
</pre>

Provide a function to reload translations for derivepassphrase

2024-12-31T18:40:01+01:00

</pre>

Add a writer function for derivepassphrase's .po template

2024-12-31T16:03:01+01:00

To be used together with the gettext toolset.

Many things are hard-coded.
</pre>

Fix some translation typos and inconsistent translation comments

2024-12-31T16:03:01+01:00

</pre>

Update the CLI to use the translatable strings

2024-12-30T23:45:01+01:00

We implement the translations in a deferred manner, via objects that
stringify to their correct translation.  Since `click` 8.1, help texts
are (mostly) stored first and processed only when the help page is
emitted.  Accordingly, this system can be adapted to support our
translatable strings: we need only ensure the help text is stringified
just before it is formatted and emitted.  This in turn can be achieved
by reimplementing the help page assembly and formatting in a custom
`click.Command` class, as has already been done to implement help/option
group support.  Once this is in place, it remains to exchange all inline
help texts with the corresponding translatable string, and adapt the
tests to the new messages.

While most of the changes are straightforward, some subtleties remain.

First, the help texts are now supplied as (separately translatable)
paragraphs to the `click.command` decorator, instead of being extracted
from the respective function docstring.  The docstrings in return have
been shortened down.

Second, since the new capabilities are implemented via custom
`click.Command`, `click.MultiCommand` and `click.Option` subclasses,
every option and command must derive from one of these classes.  This
necessitates the creation of an empty `StandardOption` class for options
without an option group, and making `_DefaultToVaultGroup` a subclass of
`CommandWithHelpGroups`.

Third, since the `click.Option` class actually processes its help text
eagerly, the subclass must hide the (non-string) help text from the
`click.Option` constructor and later restore it.

Finally, while the tests currently pass as before, they now implicitly
rely on *not* loading any translations.  Furthermore, there is no
mechanism in place with which to isolate the translation system from the
user's environment for testing purposes, nor is there a (controlled)
mechanism to test `derivepassphrase` under a different language.  Once
there are actual translations, future commits will need to establish
such a missing mechanism for translation loading/switching/forcing.
</pre>

Add more translatable strings and serialization machinery

2024-12-30T21:34:42+01:00

Add all help texts and metavars as translatable strings.  Furthermore,
add extra machinery for introspection to the serialized translatable
strings class, which will make debugging values in pytest much easier.

Add another couple of error messages (and update the manpages as well)
for low-level errors while querying the SSH agent for the key list or
while requesting a signature.  (Previously, we forwarded the internal
English exception message directly.)  Update the manpage to include
these as well.
</pre>

Extract translatable log messages into separate module

2024-12-25T21:41:22+01:00

Extract all log messages into a separate module, so that they may be
translated in a future version.  We anticipate the use of such a message
in a `logging` call, so we provide a wrapper object that defers the
string interpolation until its serialization is called, and caches the
result.  (This is all as per the recommendation from the standard
`logging` module.)  Implemented this way, it is easy to run easy
transformations on the specific log message template, e.g. substituting
a translated message template, or trimming the filename placeholder if
the filename is `None`.

As an added benefit, this organization also makes it somewhat easy to
ensure message consistency across different use sites and to generate
diagnostics lists for inclusion in the manpage.

While we intend to use the gettext toolset to implement the translation
later, we do *not* currently use the standard `_` gettext alias or
otherwise mark up the strings in an `xgettext`-compatible manner.  Both
the GNU version of `xgettext` and the Python work-alike `xgettext.py`
suck: the GNU version does not completely understand Python syntax and
cannot sensibly parse `black`-/`ruff`-formatted code using implicit
string concatenation or trailing commas in function argument lists, and
`xgettext.py` is so outdated (even in current Pythons) that it does not
support `xgettext`'s `--add-comment` option for extracting extra
comments for the translators.  So instead of attempting to cram the
strings and comments into some formatter-resistant and
`xgettext`-compatible shape (a very futile endeavor so far), store
enough information that we could generate the `.po` files ourselves with
very little additional effort.
</pre>